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Preface 



UML s'est tres rapidement impose comme le langage standard pour la mode- 
lisation objet des systemes d'information. Mais UML n'est qu'un langage, et 
dans les centaines de pages qui decrivent sa semantique et ses annexes, rien ne 
dit concretement comment il convient de s'en servir, au jour le jour, dans un 
projet reel. 

Quand Pascal Roques et Franck Vallee m'ont demande de prefacer leur 
ouvrage sur la mise en ceuvre d'UML, au travers d'une etude de cas complete, 
je me suis tout de suite dit que la redaction d'un tel ouvrage ne devait pas etre 
une chose aisee, car s'il est facile de discuter d'un projet informatique autour 
d'une tasse de cafe, il est en revanche bien difficile de decrire la demarche 
suivie et l'enchainement et la logique des activites qui ont ete menees. Le 
risque est grand de sombrer dans les details ou de se limiter a des generalites. 

UML en action evite magistralement ces ecueils et nous apporte, dans un style 
agreable a lire, une description precise et motivee d'une maniere eprouvee de 
modeliser une application informatique avec UML, depuis F analyse des 
besoins, jusqu'a la realisation finale avec Java, en passant par la description 
de F architecture et les differentes activites de conception. 

Ce livre repond parfaitement au reel besoin des informaticiens, confronted a la 
transition vers UML et a la recherche d'exemples concrets de sa mise en 
ceuvre. UML en action est le resume du savoir-faire de Pascal Roques et de 
Franck Vallee ; c'est aussi un ouvrage pragmatique et tres accessible. Je suis 
certain que sa lecture aidera beaucoup d' informaticiens a franchir avec succes 
le cap de la modelisation avec UML. 

Pierre- Alain Muller 
Professeur associe a l'Universite de Mulhouse, 
auteur du premier livre paru sur UML. 
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Chapitre Introduction 

i 



Depuis la partition, il y a maintenant neuf ans, de la premiere edition du livre 
de P.A. Muller [Muller 03] chez le meme editeur, de nombreux autres auteurs 
ont apporte leur contribution a la diffusion du langage UML, avec des points 
de vue souvent complementaires, tels que [Kettani 01] et [Soutou 02]. 

Les « peres » d'UML eux-memes ont decrit dans le detail les concepts, les 
notations et la semantique du langage dans des ouvrages de reference [UML- 
UG 05] et [UML-RM 04]. 

Alors pourquoi un autre livre sur UML ? 

Les professionnels de l'informatique cherchent regulierement des exemples 
concrets a partir desquels ils pourront elaborer leurs propres projets. C'est a 
cette preoccupation tres pragmatique que souhaite repondre ce livre qui, pour 
illustrer UML, presente une etude de cas realiste couvrant toutes les etapes du 
processus de developpement. 

Cette approche est retenue depuis longtemps a Valtech 1 , dans le cadre de 
l'offre de formation aux entreprises, en particulier pour les deux cours phares 
que sont : 

le cours « Modeliser les besoins et analyser avec UML », qui est consacre 
a la presentation generale d'UML et de son utilisation pour l'expression 
des besoins et la specification detaillee ; 

le cours « Analyse et conception avec UML », qui offre un panorama com- 
plet de l'utilisation d'UML dans une demarche de developpement de type 
Processus Unifie. 



1 . L' activite de formation a ete filialisee fin 2002 pour donner naissance a la societe Valtech 
Training, dont fait partie Pascal Roques. 
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UML en action 



Ce livre est constrait a partir de ce materiel pedagogique eprouve et de notre 
experience a l'enseigner. Cependant, notre metier de consultant ne consiste 
pas a repeter les memes formations. Dans le cadre de missions d'assistance et 
de conseil, notre offre se prolonge aupres des equipes de projets. C'est done 
cette experience du terrain ainsi que notre exigence d'aboutir a des realisa- 
tions concretes que nous avons essaye de retranscrire dans ce livre. 

En consequence, vous ne trouverez pas ici de description formelle exhaustive 
du langage UML, ni de reflexions theoriques alambiquees sur un quelconque 
aspect de sa derniere version. Mais ce livre vous montrera 1' application 
pratique d'UML a partir d'un developpement complet. C'est ainsi que vous 
apprendrez : 

a utiliser UML pour capturer les besoins des utilisateurs ; 
a analyser ces besoins avec UML ; 

puis a concevoir avec UML et les design patterns en vue d'un developpe- 
ment Java. 

En dernier point, nous vous livrons un processus de developpement qui, 
adapte au developpement des systemes Client/Serve ur, s'inscrit dans la lignee 
du « Unified Process ». 

Loin de nous pretendre exhaustifs, ou detenteurs d'une verite absolue, notre 
unique ambition consiste a presenter notre approche du developpement logi- 
ciel avec UML, afin que vous puissiez en beneficier a votre tour. 

Nota : cette quatrieme edition incorpore des nouveautes de la version 2 
d'UML 1 , en particulier au niveau des diagrammes de sequence. 

Prerequis 

Ce livre est en quelque sorte le pendant pratique de la theorie UML ; il a ete 
essentiellement pense comme le complement utile d'un ouvrage de reference 
tel que [Fowler 04] . 

Pour pouvoir en tirer pleinement profit, nous vous conseillons done de 
connaitre les rudiments de F approche objet. Les termes classe, instance, 
encapsulation, heritage et polymorphisme doivent vous etre familiers. Dans la 
plupart des cas, la pratique d'un langage de programmation objet suffit pour 
acquerir ces concepts. 



1 . Le document le plus recent utilisable lors de cette quatrieme edition a ete le « 06-04-02.pdf » 
telechargeable sur le site de L'OMG (www.uml.org). II s'agit de « UML 2.1 Superstructure 
Specification ». 
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En second lieu, il convient d' avoir compris ce qu'est une methode de developpe- 
ment logiciel qui integre notamment un support de modelisation. La connais- 
sance d'une methode de type Unified Process [Jacobson 99], de Merise, ou de 
tout autre methode orientee modelisation, vous permettra de mieux situer la 
demarche que nous mettons en pratique dans cet ouvrage. 

Ce livre ne fait que rappeler les rudiments d'UML, dans la mesure ou il existe 
aujourd'hui suffisamment d'ouvrages sur le sujet. Neanmoins, l'annexe B 
presente rapidement les diagrammes d'UML 2. 

Structure de I'ouvrage 

Cet ouvrage s'articule autour de Fetude de cas SIVEx, que vous decouvrirez 
en temps utile (chapitre 3). Comme c'est avant tout un guide pratique d' utili- 
sation d'UML dans diverses situations, il ne manque pas une occasion 
d'utiliser UML. D'ailleurs, pour presenter la structure des chapitres, nous 
avons utilise un diagramme d'activite ! 

Notre processus s'appelle le « 2 Track Unified Process » ou processus en Y ; 
il est sous-jacent a la structure du livre, comme le montre la figure 1-1. Ce 
processus est decrit plus en detail au chapitre 2, Processus et architecture. 

La premiere partie du livre fait office d'entree en matiere. 

Le chapitre 1, Introduction, correspond a la presentation de I'ouvrage. 

Le chapitre 2, Processus et architecture vous livre notre vision du processus et 
de F architecture, ainsi que l'importance que nous leur accordons. C'est 
notamment ici que vous trouverez toutes les explications sur le processus en Y. 

La seconde partie conceme la modelisation des besoins. 

Le chapitre 3, Etude preliminaire, presente le sujet de Fetude de cas 
SIVEx, et commence la modelisation de son contexte. 

Le chapitre 4, Capture des besoins fonctionnels, explique comment identi- 
fier les besoins exprimes selon le metier des utilisateurs, les reformuler, les 
structurer et les documenter avec UML. II s'appuie pour une large part sur 
la technique des cas d' utilisation. 

Le chapitre 5, Capture des besoins techniques, indique comment identifier les 
exigences qui ont trait a F exploitation d'un systeme logiciel, les reformuler, 
les structurer et les documenter avec UML. II s'appuie egalement sur les cas 
d'utilisation et introduit la notion importante de decoupage en couches. 
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UML en action 



La troisieme partie concerne 1' analyse objet. 

Le chapitre 6, Decoupage en categories, montre comment organiser la 
structure des concepts d'un systeme pour etablir une cartographie judi- 
cieuse des classes issues des besoins fonctionnels. 

Le chapitre 7, Developpement du modele statique, decrit et illustre le tra- 
vail d' analyse detaillee de la structure des classes. 

Le chapitre 8, Developpement du modele dynamique, est consacre au tra- 
vail d'analyse detaillee du comportement des classes. 



Partie 1 : UML en Action.. 



1 Introduction 



□l 



2 Processus et architecture 



Partie 2 : Capture des besoins 



3. £tude preliminaire 



I 



4, Capture des besoins fonctionnels 



5 Capture des besoins techniques 



Partie 3 : Analyse 



6. Decoupage en categories 



7 Developpement du modele statique 



z 




Partie 4 : Architecture technique 



9 Conception generique 



8 Developpement du modele dynamic 




Partie 5 : Conception 



10 Conception preliminaire . 



1 1 Conception detailtee 



>• 




Figure 1-1 



Le processus en Ysous-jacent a la structure du livre 
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La quatrieme partie concerne la conception de 1' architecture technique. 

Le chapitre 9, Conception generique, explique comment, a partir de 1' ana- 
lyse des besoins techniques, il est possible de commencer a concevoir le 
systeme, independamment de son contenu fonctionnel. 

La cinquieme partie concerne la conception objet. 

Le chapitre 10, Conception preliminaire, explique comment organiser un 
modele de conception au vu des regroupements d' analyse et des couches 
logicielles d' architecture. II illustre notamment 1' identification des compo- 
sants metier et techniques d'un systeme logiciel. 

Le chapitre 11, Conception detaillee, illustre la modelisation de solutions 
Java en appliquant differents design patterns, suivant les couches que Ton 
desire realiser. 

Ce livre comporte egalement quatre annexes et un index : 
1' annexe A qui constitue une bibliographie de reference ; 
1' annexe B qui resume la notation des diagrammes d'UML 2 ; 
1' annexe C qui dresse une synthese des mots-cles UML et des stereotypes 
utilises dans cet ouvrage ; 

1' annexe D qui recapitule les conseils et les pieges a eviter. 

Pour que vous puissiez vous reperer aisement dans 1' ouvrage, nous avons 
attribue des titres aux paragraphes traitant du processus, a savoir : 
Objectif, qui definit F expose du chapitre ; 

Quand intervient..., qui vous rappelle la position du chapitre dans le pro- 
cessus en Y et vous restitue le contexte d' intervention ; 
Elements mis en jeu, qui etablit la liste des mots-cles, techniques UML, 
concepts d' architecture et processus du chapitre ; 

Phases de realisation, qui recapitule le detail du processus utilise dans le 
chapitre ; 

Outre le texte principal, chaque chapitre est ponctue d' insertions facilement 
reperables grace aux icones suivantes : 



0 © 

Definition 



RAPPEL OU ENONCE D'UNE DEFINITION 



c 

Conseil 



NOUS VOUS CONSEILLONS DE. 
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UML en action 



o 

Ne pas foire 



NOUS VOUS DECONSEILLONS FORTEMENT DE... 



Etude 



APPROFONDISSEMENT D'UN POINT PARTICULIER 



Comment lire UML en Action. 



La grille de lecture est en partie dediee a nos homologues consultants qui ont 
rarement le temps de lire un ouvrage jusque dans ses moindres details. Aussi 
avons-nous etabli la specification fonctionnelle de notre ouvrage. . . en UML. 

Les lecteurs que nous avons identifies sont represented dans la nomenclature 
de la figure suivante. 



Lecteur 

A 



Chef de projet 
Maitre d'oeuwe 



Developpeur 



Archrtecte togiciel 



Maitre d'ouvrage 



Architecte 

Concepts, , echn|que 



Analyste 

Figure 1-2 : Typologie des lecteurs de UML en action... 

Le lecteur « Maitre d'ouvrage » est client du systeme a developper. II participe 
a la specification en representant le metier des utilisateurs ; il est done 
implique dans l'analyse objet. II s'interesse egalement au processus de deve- 
loppement afin de s' assurer que les dispositions necessaires a la reussite du 
projet ont ete prises. 

Le lecteur « Chef de projet » appartient a la maitrise d'eeuvre. II s'interesse a 
l'aspect gestion du developpement et doit inciter a l'utilisation des meilleures 
pratiques de developpement. C'est pourquoi il est directement concerne par 
toutes les techniques de modelisation objet presentees dans cet ouvrage. 
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Le lecteur « Developpeur » represente un membre de l'equipe de developpe- 
ment. II est soit analyste, soit concepteur, soit successive ment les deux. En 
fonction de son role, il est interesse par les techniques de modelisation objet 
soit pour F analyse, soit pour la conception. 

Le lecteur « Architecte technique » met en ceuvre les outils, les langages et les 
plates-formes necessaires a l'equipe de developpement. II est concerne par la 
modelisation d'une conception objet, avec laquelle il va construire les compo- 
sants techniques requis par les developpeurs. 

Le lecteur « Architecte logiciel » est charge de structurer et d' organiser le 
systeme informatique. Son interet se porte par consequent sur les modeles 
d' analyse qu'il doit integrer au niveau conceptuel et sur les modeles de 
conception au niveau logiciel. II trouvera egalement les techniques permettant 
de concevoir les briques, reutilisables ou non, avec lesquelles est faconne un 
systeme informatique resilient et evolutif. 

Des cas d'utilisation structurent le contexte dans lequel Fouvrage peut etre utilise 
par les differents lecteurs. C'est encore une bonne occasion d'utiliser UML. 




Chef de projet 
Maitrise d'oeuvre 



Architecte logiciel 



Comprendre un processus de 
developpement 
objet 




Concevoir une architecture 
technique 



Organiser un logiciel 

Figure 1-3 : Les cas d'utilisation de UML en Action. 



Concepteur 



Maitre d'ouvrage 



Architecte 

tec^-:q„e 



Developpeur 



Cette courte analyse des besoins concernant UML en Action... aboutit a la 
grille de lecture ci-dessous. 
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UML en action 



Qui 


Fait quoi 


Comment 


Le lecteur 


lit UML en Action... 


de maniere sequentielle. 


Le lecteur 


recherche les 
informations 


grace a nos differents outils de recherche : I'index, la cartographie 
du processus, les titres « Elements mis en jeu » et « Phases de 
realisation » de chaque chapitre et enfin la bibliographie. 


L'analyste 


procede a une 
analyse objet 


doit lire dans I'ordre le chapitre 3, Etude preliminaire, pour 
comprendre la teneur fonctionnelle de SIVEx, le chapitre 4, 
Capture des besoins fonctionnels, puis la troisieme partie concer- 
nant I'analyse objet. 


Le concepteur 


procede a une 
conception objet 


doit lire le chapitre 9, Conception generique, pour comprendre 
comment concevoir des composants techniques, puis la cinquieme 
partie dediee a la conception objet. 


Le maitre 
d'ouvrage, le 
chef de projet, 
I'architecte 


comprennent un 
processus objet 


doivent se referer au chapitre 2, Processus et architecture, puis 
aux titres «Quand intervient...» et "Phases de realisation" de 
chaque chapitre. 


Les architectes 
technique et 
logiciel 


concoivent une 

architecture 

technique 


doivent consulter le chapitre 5, Capture des besoins techniques, 
pour voir comment en acquerir les specifications, puis la quatrieme 
partie consacree a I'architecture technique. 


L'architecte 
logiciel 


organise un 
systeme logiciel 


doit lire le chapitre 2, Processus et architecture, introduisant les 
termes d'architecture, le chapitre 6, Decoupage en categories, 
pour comprendre I'organisation conceptuelle, le chapitre 9, 
Conception generique, qui concerne I'organisation technique et 
logicielle, et le chapitre 10, Conception preliminaire, qui traite de 
I'organisation en composants. 
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Enfin, un grand merci a nos families, avec une mention particuliere a Pascale 
et Fabienne, qui nous ont soutenus et encourages tout au long de cette petite 
aventure. 
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Une introduction 
aux processus unifies 



La complexite croissante des systemes informatiques a conduit les concep- 
teurs a s'interesser aux methodes. Bien que ce phenomene ait plus de 30 ans, 
nous ne pouvons constater aujourd'hui 1' existence d'une regie qui soit a la 
fois tres formelle et commune aux differentes cultures. On a par exemple 
comptabilise en 1994 jusqu'a 50 methodes objets differentes. Chaque 
methode se definit par une notation et un processus specifique, mais la plupart 
convergent en ce qui concerne la semantique de leur notation. Neanmoins le 
travail de definition d'un processus est toujours reste vague et succinct. UML 
a ouvert le terrain de 1' unification en fusionnant les notations et en apportant 
precision et rigueur a la definition des concepts introduits. L' introduction 
d'UML a apporte un elan sans precedent a la technologie objet, puisqu'elle y 
propose un standard de niveau industriel. 

II reste cependant a definir le processus pour reellement capitaliser des regies 
dans le domaine du developpement logiciel. Definir un seul processus 
universel serait une grave erreur car la variete des systemes et des techniques 
ne le permet pas. Dans la lancee d'UML, les 3 amigos 1 ont done travaille a 
unifier non pas les processus, mais plus exactement les meilleures pratiques de 
developpement oriente objet. Le resultat de ces travaux est actuellement 
disponible dans [Jacobson 99] et [Kruchten 03] et surtout dans le produit 
commercial RUP de IBM/Rational. 



1. Denomination de Grady Booch, James Rumbaugh, et Ivar Jacobson qui sont les « peres » 
d'UML. 
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PROCESSUS DE DEVELOPPEMENT LOSICIEL 

Un processus definit une sequence d'etapes, en partie ordonnees, qui 
concourent a Fobtention d'un systeme logiciel ou a revolution d'un systeme 
existant. 

L'objet d'un processus de developpement est de produire des logiciels de 
qualite qui repondent aux besoins de leurs utilisateurs dans des temps et des 
couts previsibles. En consequence, le processus peut se decomposer suivant 
deux axes de controle sur le developpement : 

l'axe de developpement technique, qui se concentre principalement sur la 
qualite de la production ; 

l'axe de gestion du developpement, qui permet la mesure et la prevision 
des couts et des delais. Nous ne traitons pas cet aspect dans « UML en 
Action... ». 



o 

Definition 



PROCESSUS UNIFIE (UNIFIED PROCESS) 

Un processus unifie est un processus de developpement logiciel construit sur 
UML ; il est iteratif et incremental, centre sur 1' architecture, conduit par les 
cas d'utilisation et pilote par les risques. 

La gestion d'un tel processus est organisee d'apres les 4 phases suivantes: 
preetude (inception), elaboration, construction et transition. 

Ses activites de developpement sont definies par 6 disciplines fondamentales 
qui decrivent la modelisation metier, la capture des besoins, l'analyse et la 
conception, F implementation, le test et le deploiement. 

Le processus unifie doit done etre compris comme une trame commune des 
meilleures pratiques de developpement, et non comme l'ultime tentative 
d'elaborer un processus universel. La definition d'un processus UP est done 
constitute de plusieurs disciplines d'activite de production et de controle de 
cette production. Tout processus UP repond aux caracteristiques ci-apres. 
II est iteratif et incremental. La definition d' iterations de realisation est en 
effet la meilleure pratique de gestion des risques d'ordre a la fois techni- 
que et fonctionnel. On peut estimer qu'un projet qui ne produit rien d'exe- 
cutable dans les 9 mois court un risque majeur d'echec. Chaque iteration 
garantit que les equipes sont capables d'integrer l'environnement techni- 
que pour developper un produit final et fournit aux utilisateurs un resultat 
tangible de leurs specifications. Le suivi des iterations constitue par 
ailleurs un excellent controle des couts et des delais. 



Chapitre 2 • Processus et architecture 



13 



II est pilote par les risques. Dans ce cadre, les causes majeures d'echec 
d'un projet logiciel doivent etre ecartees en priorite. Nous identifions une 
premiere cause provenant de l'incapacite de 1' architecture technique a 
repondre aux contraintes operationnelles, et une seconde cause liee a l'ina- 
dequation du developpement aux besoins des utilisateurs. 

II est construit autour de la creation et de la maintenance d'un modele, plu- 
tot que de la production de montagnes de documents. Le volume d'infor- 
mations de ce modele necessite une organisation stricte qui presente les 
differents points de vue du logiciel a differents degres d' abstraction. 
L'obtention de metriques sur le modele fournit par ailleurs des moyens 
objectifs d' estimation. 

II est oriente composant. Tant au niveau modelisation que production, 
c'est une garantie de souplesse pour le modele lui-meme et le logiciel qu'il 
represente. Cette pratique constitue le support necessaire a la reutilisation 
logicielle et offre des perspectives de gains non negligeables. 

II est oriente utilisateur, car la specification et la conception sont construi- 
tes a partir des modes d'utilisation attendus par les acteurs du systeme. 



Le processus 2TUP 

2TUP signifie « 2 Track Unified Process ». C'est un processus UP qui repond 
aux caracteristiques que nous venons de citer. Le processus 2TUP apporte une 
reponse aux contraintes de changement continuel imposees aux systemes 
d'information de l'entreprise. En ce sens, il renforce le controle sur les capa- 
cites d'evolution et de correction de tels systemes. « 2 Track » signifie littera- 
lement que le processus suit deux chemins. II s'agit des chemins 
« fonctionnels » et « d' architecture technique », qui correspondent aux deux 
axes de changement imposes au systeme informatique. 



Contraintes 
fonctionnelles 



Systeme 
d'information 
d'entreprise 



Contraintes 
techniques 



Figure 2-1 : Le systeme d'information soumis a deux natures de contraintes 



L'axiome fondateur du 2TUP consiste a constater que toute evolution imposee 
au systeme d'information peut se decomposer et se traiter parallelement, 
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suivant un axe fonctionnel et un axe technique. Pour illustrer cet axiome, 
prenons les trois exemples suivants : 

1 . une agence de tourisme passe des accords avec une compagnie aerienne de 
sorte que le calcul des commissions change. En l'occurrence, les resultats 
issus de la branche fonctionnelle qui evoluent pour prendre en compte la 
nouvelle specification ; 

2. cette meme entreprise decide d'ouvrir la prise de commande sur le Web. Si 
rien ne change fonctionnellement, en revanche, F architecture technique du 
systeme evolue ; 

3. cette entreprise decide finalement de partager son catalogue de prestations 
avec les vols de la compagnie aerienne. D'une part, la fusion des deux 
sources d' informations imposera une evolution de la branche fonction- 
nelle, d' autre part, les moyens techniques de synchronisation des deux sys- 
temes conduiront a etoffer 1' architecture technique du systeme. L' etude de 
ces evolutions pourra etre menee independamment, suivant les deux bran- 
ches du 2TUP. 

A Tissue des evolutions du modele fonctionnel et de 1' architecture technique, 
la realisation du systeme consiste a fusionner les resultats des deux branches. 
Cette fusion conduit a l'obtention d'un processus de developpement en forme 
de Y, comme illustre par la figure 2-2. 

Branche 










Capture des besoins 




fonctionnels 



technique 



Analyse 



ZZ 



Capture des besoins 
techniques 

/ / 



Contra intes 
techniques 



Conception prelim inaire 



Conception generique 



Conception detaillee 



prototype 



Cod age et tests 




Recette 



Figure 2-2 : Le processus de developpement en Y 

La branche gauche (fonctionnelle) comporte : 

la capture des besoins fonctionnels, qui produit un modele des besoins 
focalise sur le metier des utilisateurs. Elle qualifie au plus tot le risque de 
produire un systeme inadapte aux utilisateurs. De son cote, la maitrise 
d'eeuvre consolide les specifications et en verifie la coherence et l'exhaus- 
tivite 1' analyse, qui consiste a etudier precisement la specification fonc- 
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tionnelle de maniere a obtenir une idee de ce que va realiser le systeme en 
termes de metier. Les resultats de F analyse ne dependent d'aucune techno- 
logie particuliere. 

La branche droite (architecture technique) comporte : 

la capture des besoins techniques, qui recense toutes les contraintes et les 
choix dimensionnant la conception du systeme. Les outils et les materiels 
selectionnes ainsi que la prise en compte de contraintes d' integration avec 
l'existant conditionnent generalement des preiequis d' architecture technique ; 
la conception generique, qui definit ensuite les composants necessaires a 
la construction de 1' architecture technique. Cette conception est la moins 
dependante possible des aspects fonctionnels. Elle a pour objectif d'uni- 
formiser et de reutiliser les memes mecanismes pour tout un systeme. 
L architecture technique construit le squelette du systeme informatique et 
ecarte la plupart des risques de niveau technique. L importance de sa reus- 
site est telle qu'il est conseille de realiser un prototype pour assurer sa vali- 
dity . 

La branche du milieu comporte : 

la conception preliminaire, qui represente une etape delicate, car elle inte- 
gre le modele d'analyse dans l'architecture technique de maniere a tracer 
la cartographie des composants du systeme a developper ; 
la conception detaillee, qui etudie ensuite comment realiser chaque com- 
posant ; 

1' etape de codage, qui produit ces composants et teste au fur et a mesure 
les unites de code realisees ; 

1' etape de recette, qui consiste enfin a valider les fonctions du systeme 
developpe. 

L ensemble de ces etapes de developpement sera illustre tout au long de cet 
ouvrage par la mise en application du processus 2TUP a F etude de cas SIVEx. 
Seules les deux dernieres etapes, ne relevant pas de l'utilisation d'UML, ne 
seront pas abordees dans cet ouvrage. 



LES BRANCHES DU "Y" PRODUISENT DES MODELES REUTILISABLES 

La branche gauche capitalise la connaissance du metier de l'entreprise. Elle 
constitue generalement un investissement pour le moyen et le long terme. 
Les fonctions du systeme d' informations sont en effet independantes des 
technologies utilisees. Cette evidence n'a malheureusement pas souvent ete 
mise en pratique, car dans bien des cas, la connaissance fonctionnelle d'un 
produit se perd dans les milliers de ligne de code de sa realisation. 
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L'entreprise qui maintient le modele fonctionnel de sa branche gauche est 
pourtant a meme de le realiser sous differentes technologies. II suffit de 
« greffer » une nouvelle architecture technique pour mettre a jour un sys- 
teme existant. 




Configuration I Configuration! 



La branche droite capitalise quant a elle un savoir-faire technique. Elle cons- 
titue un investissement pour le court et le moyen terme. Les techniques 
developpees pour le systeme peuvent l'etre en effet independamment des 
fonctions a realiser. 

L' architecture technique est d'ailleurs de moins en moins la preoccupation 
des services informatiques dont l'entreprise n'a pas vocation a produire du 
code. L' existence de produits tels que les serveurs d'application ou la stan- 
dardisation des services Web refiete cette tendance a pouvoir disposer sur le 
marche d' architectures techniques « pretes a integrer ». 

Une architecture technique est en effet immediatement reutilisable pour les 
differentes composantes fonctionnelles d'un meme systeme d'entreprise. 




Architecture 
technique 
(reutilisee) 



Systeme de gestion commerciale Systeme de gestwn de production 



Un processus iteratif et incremental pilote par les risques 




ITERATION 



Une iteration est une sequence distincte d'activites avec un plan de base et 
des criteres d'evaluation, qui produit une release (interne ou externe). Le 
contenu d'une iteration est porteur d' ameliorations ou d' evolutions du sys- 
teme et il peut etre evalue par les utilisateurs. 
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INCREMENT 

Un increment est la difference (delta) entre deux releases produites a la fin 
de deux iterations successives. 

Une ou plusieurs iterations s'inscrivent dans chacune des phases de gestion de 
projet et servent en consequence a realiser l'objectif propre a chaque phase. 

En preetude (inception), les iterations servent a evaluer la valeur ajoutee 

du developpement et la capacite technique a le realiser. 

En phase d' elaboration, elles servent a confirmer F adequation du systeme 

aux besoins des utilisateurs et a livrer 1' architecture de base. 

En phase de construction, elles servent a livrer progressivement toutes les 

fonctions du systeme. 

En phase de transition, elles servent a deployer le systeme sur les sites ope- 
rationnels. 

Le processus de developpement en Y se reproduit a differents niveaux d'avan- 
cement en se terminant sur la livraison d'une nouvelle release. La figure 2-3 
illustre un scenario typique d'avancement sur les 3 premieres phases de 
gestion de projet. 



Preetude 


7 

Elaboration 


Construction 




V 




Iteration 1 


Iter. 2 Iter. 3 


Iter. 4 Iter. 5 Iter. 6 



Temps... 

Figure 2-3 : Plan d'iteration suivant I'axe de gestion de projet 

L iteration 1 developpe les fonctions de validation du principe du systeme 
et integre les outils prevus pour le developpement. 

L iteration 2 est focalisee sur F architecture ; elle peut etre considered 
comme le prototype de realisation technique. 

L iteration 3 avance dans la realisation des fonctions les plus prioritaires 
de maniere a presenter une premiere version de deploiement pour les utili- 
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sateurs. Elle permet entre-temps d'ameliorer et de completer F architecture 
technique. 

Les iterations suivantes avancent dans la realisation des fonctions jusqu'a 
l'obtention complete du systeme initialement envisage. 

Par definition, chaque iteration passe en revue toutes les activites du processus 
en Y. II est evident que F effort consacre a chaque activite n'est pas identique 
suivant la phase de developpement du projet. 

Pour reprendre Fexemple precedent, on peut estimer que Fiteration de pree- 
tude consacre relativement plus d' efforts a la capture des besoins que les itera- 
tions d' elaboration. Le tableau ci-dessous etablit pour chaque phase, un ordre 
de grandeur des efforts consacres. Ces chiffres ne constituent en aucun cas une 
reference qui puisse etre reutilisee telle que dans votre projet. 



Effort relatif par activite 


Iteration 1 


Iteration 2 


Iteration 4 


(preetude) 


(elaboration) 


(construction) 


Capture des besoins fonctionnels 


16% 


1 % 


2% 


Analyse 


22% 


9% 


4% 


Capture des besoins techniques 


2% 


4% 


0% 


Conception generique 


5% 


14% 


2% 


Conception preliminaire 


10% 


10% 


10% 


Conception detaillee 


10% 


14% 


20% 


Codage et tests 


28% 


26% 


30% 


Recette 


7% 


22% 


32% 


(Total des activites du Y) 


100% 


100% 


100% 



Tableau 2-1 : Exemple de repartition des efforts par activite suivant les differentes phases du projet 



LES EFFORTS CONSACRES A CHAQUE ITERATION NE S'ARRETENT PAS AUX 
ACTIVITES DU Y 

Le processus en Y est focalise sur les seules activites de developpement 
technique, mais en realite, la fabrication d'un increment necessite deux types 
d'activites support dont il faut tenir compte dans Festimation des efforts. 

Les taches d' industrialisation du logiciel concernent la mise en place des 
moyens qui vont permettre un developpement de qualite. On y regroupe les 
activites d' administration et d' appropriation des outils de developpement, 
ainsi que la gestion de configuration tres importante pour le controle du 
changement. 



Etude 
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Etude 



Les taches de pilotage regroupent les efforts consacres a controler et a antici- 
per Favancement du projet. Elles comprennent egalement les temps de reu- 
nion et de coordination. 



i 




Tdches » ^Kf ▼ T&ches 

de pilotage du projet d' industrialisation du 

Taches de togiciel 
developpement logiciel 



Les phases definies par un UP sont prevues pour la gestion des risques. 
Comme on l'a vu au paragraphe precedent, le couplage avec une politique 
d' iterations permet de traiter en priorite les problemes presentant le plus de 
risques. 

La configuration du processus en Y a egalement ete concue pour gerer en 
priorite et en parallele les risques de nature fonctionnelle et technique : 

d'une part, les risques d' imprecision fonctionnelle, et d'inadequation aux 
besoins sur la branche gauche, 

d'autre part les risques d'incapacite a integrer les technologies, et d'ina- 
daptation technique sur la branche droite. 

II est d'usage de consacrer la phase de preetude a l'etude des fonctionnalites 
que produira le systeme logiciel. Afin de pallier un risque courant d'impreci- 
sion dans la definition fonctionnelle du systeme, les techniques de formalisa- 
tion du contexte (voir chapitre 3) vous aideront a etablir la frontiere entre le 
systeme et le reste du monde. 

L exigence d'aboutir a une premiere release permet egalement d'evaluer tres 
rapidement la capacite a integrer les technologies necessaires au projet. A 
Tissue de la phase de preetude, un choix s'impose : faut-il continuer ou non le 
projet ? Pour y repondre, le suivi des efforts est un element cle qui permet 
d'estimer la rentabilite globale du projet. 

La phase d' elaboration est ensuite consacree au developpement de 1' architecture 
technique et a la realisation des fonctions les plus prioritaires. A Tissue de cette 
phase, le comportement technique du systeme (temps de reponse, tenue en 
charge, robustesse, etc.) et son accueil par les utilisateurs (reponse aux besoins, 
ergonomie, etc.) doivent ecarter definitivement tous les risques d'echec. 
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Un processus pilote par les exigences des utilisateurs 

Comme nous l'avons souligne precedemment, un bon nombre de risques 
proviennent de la non-adequation technique et fonctionnelle du systeme aux 
besoins des utilisateurs. Les exigences des utilisateurs sont done prioritaire- 
ment traitees dans les deux branches du processus en Y en considerant deux 
types d'acteurs differents du systeme informatique : 

l'utilisateur consommateur des fonctions du systeme, qui correspond 
generalement a un poste, un role ou un metier dans Fentreprise. II convient 
dans ce cadre de se focaliser sur la plus-value que lui apporte le systeme 
dans l'exercice de sa profession ; 

l'utilisateur exploitant le systeme, qui correspond plutot a un role technique 
et operationnel commun a la plupart des systemes informatiques. Dans le 
domaine client/serveur, les utilisateurs, considered au sens large, attendent 
des performances, une tenue a la charge, une securite d'acces, etc. L'axe 
technique permet egalement d'introduire le point de vue des exploitants et 
des administrateurs souvent oublies dans la livraison finale d'un produit. 

L'enjeu du processus en Y est done de developper le point de vue utilisateur et 
de construire la specification puis la conception objet a partir des concepts 
manies par les acteurs du systeme. Les cas d'utilisation sont justement des 
outils construits pour definir les besoins, developpant de surcroit le point de 
vue des utilisateurs. II convient par la suite de montrer comment s'etablit la 
tracabilite entre les cas d'utilisation et le modele de conception. La figure 2- 
4 montre comment les cas d'utilisation influencent l'analyse et la conception 
d' architecture du systeme. 

Sur la branche gauche, pour la capture des besoins fonctionnels, les cas 
d'utilisation portent uniquement sur la plus-value metier des fonctions du 
systeme. Chaque cas d'utilisation met en evidence des classes d' analyse 
qui sont les concepts utilises par l'utilisateur et des scenarios qui etablis- 
sent les comportements attendus du systeme. 

Sur la branche droite, pour la capture des besoins techniques, la nature des 
cas d'utilisation a ete quelque peu adaptee en fonction des plus-values 
operationnelles du systeme pour ses exploitants. Chaque cas d'utilisation 
technique structure des specifications d' architecture que Ton peut par la 
suite decomposer par couche logicielle. Les cas d'utilisation techniques 
permettent de concevoir les classes qui vont offrir une reponse aux con- 
traintes operationnelles du systeme. Les interactions entre ces classes per- 
mettent par ailleurs d'etudier les echanges entre classes, de consolider et 
de verifier la conception des cas d'utilisation techniques. 
Lors de la conception preliminaire, les classes obtenues naissent de la dis- 
tribution des classes d' analyse sur les couches logicielles. Les interactions 
entre classes de conception permettent de consolider et de verifier a terme 
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la conception des cas d' utilisation fonctionnelle tenant compte des 
contraintes operationnelles. 



liranche 
fonctionnelle 



liranche 
technique 



Capture des 

besoms 

fonctionnels 



fonctionnel 
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techniques 
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generique 



Conception preliminaire 



Conception detaillee 



Figure 2-4 : Influence des cas d'utilisation dans le processus en Y 

Au travers des cas d'utilisation, le point de vue utilisateur a done bien le role 
d' initiation souhaite pour une conception. Vous noterez par ailleurs que 
1' orientation metier imposee par les cas d'utilisation de la branche gauche 
renforce la plus-value apportee par le systeme et introduit une dimension 
d' analyse de la valeur. 

Le pilotage par les cas d'utilisation consiste justement a ordonner les cas 
d'utilisation par priorite, de maniere a organiser les iterations par valeur 
ajoutee. En phase de construction notamment, e'est une bonne pratique 
d'inclure les cas d'utilisation les plus prioritaires en realisation des premieres 
iterations, puis de continuer par ordre de priorite. En apportant au plus tot le 
maximum de valeur ajoutee au systeme, on rentabilise plus rapidement le 
developpement, ce qui est encore une maniere de reduire les risques. 



Un processus de modelisation avec UML 

II nous parait difficile d'envisager le processus 2TUP sans recourir a UML 
comme support. Certes, les concepts presentes jusqu'a present ne sont pas 
specifiquement lies a une notation particuliere. Nous avons cependant omis de 
preciser le role central et fondamental de la modelisation objet tout au long du 
developpement d'une solution logicielle. 

Le recours a la modelisation est depuis longtemps une pratique indispensable au 
developpement, car un modele est prevu pour anticiper les resultats du develop- 
pement. Un modele est en effet une abstraction du resultat, dont le but est de 
documenter, de prevoir, d'etudier, de collecter ou d'estimer les informations 
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d'un systeme. Associe au processus de developpement, un modele represente la 
vue sur une specification ou sur une solution de systeme, pris a un niveau de 
detail pertinent pour exprimer ou concevoir la cible de l'etape en cours. 

Le modele sert done des objectifs differents suivant l'etape de developpement 
et sera construit avec des points de vue de plus en plus detailles : 

dans les activites de capture des besoins, il convient premierement de con- 
siderer le systeme comme une boite noire a part entiere afin d'etudier sa 
place dans le systeme metier plus global qu'est l'entreprise. On developpe 
pour cela un modele de niveau contexte, afin de tracer precisement les 
frontieres fonctionnelles du systeme ; 

dans les activites d' analyse, le modele represente le systeme vu de l'inte- 
rieur. II se compose d'objets representant une abstraction des concepts 
manipules par les utilisateurs. Le modele comprend par ailleurs deux 
points de vue, la structure statique et le comportement dynamique. II s'agit 
de deux perspectives differentes qui aident a completer la comprehension 
du systeme a developper ; 

dans les activites de conception, le modele correspond aux concepts qui sont 
utilises par les outils, les langages ou les plates-formes de developpement. 
Le modele sert ici a etudier, documenter, communiquer et anticiper une solu- 
tion. II est en effet toujours plus rentable de decouvrir une erreur de concep- 
tion sur un modele, que de le decouvrir au bout de milliers de lignes codees 
sans grands horizons. Pour la conception du deploiement enfin, le modele 
represente egalement les materiels et les logiciels a interconnecter ; 

en dernier lieu, l'utilisation extensive de modeles dans les dernieres phases 
de conception, ainsi que le caractere systematique qui s'esquisse dans le pas- 
sage d'UML au code ont permis d'elaborer les fondements de l'approche 
MDA (voir definition ci-apres). Dans ce cadre, le modele devient directe- 
ment executable, de sorte que la derniere etape fastidieuse du codage 
devienne presque inutile. L'approche MDA, qui remet au gout du jour le 
concept de programmation graphique, devient envisageable a Tissue d'une 
longue maturation du genie logiciel ; elle est en effet le resultat de differents 
concepts que sont : la structuration orientee objet, la formalisation plus pous- 
see du metamodele d'UML 2, la programmation orientee aspect, la standar- 
disation des langages de programmation, constatee au travers des plates- 
formes de developpement (Java et C# notamment), et des composants IHM, 
Web (W3C) et bases de donnees pour l'essentiel. 

Pour illustrer au mieux ce qu'est un modele, Grady Booch [UML-UG 05] a 
etabli un parallele entre le developpement logiciel et la construction BTP Cette 
analogie est judicieuse, car les plans traces pour construire un immeuble refle- 
tent parfaitement bien l'idee d' anticipation, de conception et de documentation 
du modele. Chaque plan developpe par ailleurs un point de vue different suivant 



Chapitre 2 • Processus et architecture 



23 



les corps de metier. Par exemple, le plan des circuits d'eau et le plan des 
passages electriques concernent le meme immeuble mais sont necessairement 
separes. Enfin, chaque plan se situe a un niveau d' abstraction et de detail 
distinct suivant Fusage que Ton desire en faire. Ainsi, le plan de masse permet 
d'anticiper les consequences de l'implantation de l'immeuble sur son environ- 
nement, exactement comme le modele de contexte. Viennent ensuite des plans 
de construction d'un etage, analogues aux modeles de conception. 

Le modele en tant qu' abstraction d'un systeme s'accorde parfaitement bien avec 
le concept oriente objet. L'objet represente en effet l'abstraction d'une entite 
utilisee dans le systeme en analyse, puis le modele d'un composant de solution 
logicielle en conception. La correspondance est encore plus flagrante, et le 
modele encore plus precis, lorsque les outils de developpement sont eux-memes 
orientes objet. Aujourd'hui, le standard industriel de modelisation objet est UML. 

© |gt> 

Definition Iwl l^ 

"P^ « UNIFIED MODELING LANGUAGE » 

UML se definit comme un langage de modelisation graphique et textuel des- 
tine a comprendre et decrire des besoins, specifier et documenter des syste- 
mes, esquisser des architectures logicielles, concevoir des solutions et 
communiquer des points de vue. 

UML unifie a la fois les notations et les concepts orientes objet. II ne s'agit 
pas d'une simple notation, mais les concepts transmis par un diagramme ont 
une semantique precise et sont porteurs de sens au meme titre que les mots 
d'un langage. UML a une dimension symbolique et ouvre une nouvelle voie 
d'echange de visions systemiques precises. Ce langage est certes issu du deve- 
loppement logiciel mais pourrait etre applique a toute science fondee sur la 
description d'un systeme. Dans l'immediat, UML interesse fortement les 
specialistes de l'ingenierie systeme. 

UML unifie egalement les notations necessaires aux differentes activites d'un 
processus de developpement et offre, par ce biais, le moyen d'etablir le suivi des 
decisions prises, depuis la specification jusqu'au codage. Dans ce cadre, un 
concept appartenant aux besoins des utilisateurs projette sa realite dans le modele 
de conception et dans le codage. Le fil tendu entre les differentes etapes de cons- 
truction permet alors de remonter du code aux besoins et d'en comprendre les 
tenants et les aboutissants. En d'autres termes, on peut retrouver la necessite d'un 
bloc de codes en se referant a son origine dans le modele des besoins. 

En complement d'UML, il nous parait important d'introduire deux concepts qui 
tendent a prendre une place preponderante dans le processus moderne de deve- 
loppement logiciel : MDA et AOP. 
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Q MDA : « MODEL DRIVEN ARCHITECTURE » 

Definition MDA tend a produire une approche standard de F utilisation d'UML en tant 
que langage de programmation. Le standard MDA fait partie des travaux de 
FOMG au meme titre que CORBA et UML et a fait l'objet, ces deux dernie- 
res annees, d'une forte activite d' innovation. 

L'objectif de MDA est done de definir une plate-forme capable d'executer un 
modele UML, assorti de regies OCL et d' aspects, et ainsi rendu executable 
(le lecteur trouvera ci-dessous une definition de la programmation orientee 
aspect et plus loin dans l'ouvrage une description d'OCL - Object Cons- 
traint Language). 

MDA propose une architecture en deux sous-modeles que sont le PIM (Plat- 
form Independant Model) et le PSM (Platform Specific Model). Le premier 
permet de modeliser un comportement cible sans se soucier des technologies 
sous-jacentes et particulierement de l'outil MDA utilise afin de garantir a 
terme un premier niveau d'interoperabilite entre les outils. Le second modele 
est facultativement decrit en UML, car il represente F implementation des 
directives de conception vis-a-vis de la plate-forme visee. Suivant la strategic 
adoptee par Fediteur de l'outil MDA, le PSM peut generer du code interme- 
diaire ou bien rendre le modele directement executable au travers de moteurs 
d' interpretation. 

Le courant MDA represente un potentiel de developpement important pour 
UML, car il apporte a ce dernier une valorisation encore plus significative 
aux projets informatiques. C'est pourquoi UML 2 apporte un soutien parti- 
culier a ce projet en renforcant la formalisation du meta-modele et du lan- 
gage de description de regies OCL. 
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AOP : « ASPECT ORIENTED PROGRAMMING » 

AOP represente une technique qui consiste a introduire des zones de descrip- 
tion du comportement technique du code dans la programmation. La philo- 
sophic de l'AOP consiste en effet a considerer que seules les differences 
metier justifient que des codes produisant le meme mecanisme technique, 
par essence reutilisable, soient differents. Le comportement de persistance 
d'un objet est par exemple un aspect qu'il convient de decrire dans une zone 
separee du contenu metier de l'objet, de sorte que ce contenu soit interopera- 
ble quelle que soit la cible technique visee, par exemple : base de donnees 
relationnelle ou fichier XML. 

Par extension, la programmation orientee aspect peut etre assimilee a un 
courant plus global dans lequel on regroupe un eventail de techniques parta- 
geant toutes la meme perspective de decrire les comportements techniques 
d'un composant plutot que de les programmer. Cet eventail comprend aussi 
bien les fichiers de deploiement des EJB que les archetypes reutilisables de 
conception decrits par Steve Mellor dans Executable UML [Mellor 02]. On 
retrouvera egalement cette meme approche au travers de la propriete « 
design tip » que nous avons introduite, des sa premiere edition, au chapitre 
1 1 de cet ouvrage. 

Les diagrammes d'UML 2 

UML s'articule maintenant autour de 13 diagrammes differents, dont 4 
nouveaux diagrammes introduits par UML 2.0. Chacun d'eux est dedie a la 
representation d'un systeme logiciel suivant un point de vue particulier. Par 
ailleurs, UML modelise le systeme suivant deux modes de representation : 
l'un concerne la structure du systeme pris « au repos », 1' autre concerne sa 
dynamique de fonctionnement. Les deux representations sont necessaires et 
complementaires pour schematiser la facon dont est compose le systeme et 
comment ses composantes fonctionnent entre elles. 

Le mode de representation statique ou structurel s'appuie sur les 
7 diagrammes ci-apres. 

Le diagramme de cas d' utilisation represente la structure des fonctionnalites 
necessaires aux utilisateurs du systeme. II est utilise dans les deux etapes de 
capture des besoins fonctionnels et techniques. Vous en retrouverez une 
description detaillee de son usage aux chapitres 4 et 5 de cet ouvrage. 
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Figure 2-5 : Diagramme de cas d'utilisation 

Le diagramme de classes est generalement considere comme le plus 
important dans un developpement oriente objet. Sur la branche fonction- 
nelle, ce diagramme est prevu pour developper la structure des entites 
manipulees par les utilisateurs. Vous retrouverez les explications relatives 
a cette utilisation aux chapitres 4, 6 et 7. En conception, le diagramme de 
classes represente la structure d'un code oriente objet, ou au mieux les 
modules du langage de developpement. Vous retrouverez l'utilisation du 
diagramme de classes en conception aux chapitres 9, 10 et 11. 
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Figure 2-6 : Diagramme de classes 

Le diagramme de packages est l'officialisation par UML 2.0 d'une prati- 
que d'UML 1.x qui consiste a utiliser un diagramme de classes pour y 
representer la hierarchie des modules (categories) d'un projet. Vous trou- 
verez les details de ce diagramme au chapitre 6 de cet ouvrage. 
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Figure 2-7 : Diagramme de packages 

Le diagramme d'objets sert a illustrer des structures de classes compli- 
quees en montrant des exemples d'instances. Ce diagramme est utilise en 
analyse pour verifier F adequation d'un diagramme de classes a differents 
cas possibles. Vous retrouverez l'utilisation d'un tel diagramme en analyse 
au chapitre 7. 
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Figure 2-8 : Diagramme d'objets 



Le diagramme de structure composite decrit la composition d'un objet 
complexe lors de son execution. Ce diagramme est propre a UML 2 ; il 
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introduit la notion de structure d'un objet complexe, tel qu'il se presente 
en phase de run-time. 
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Figure 2-9 : Diagramme de structure composite 

Le diagramme de composants represente les concepts connus de l'exploi- 
tant pour installer et depanner le systeme. II s'agit dans ce cas de dete- 
rminer la structure des composants d' exploitation que sont les librairies 
dynamiques, les instances de bases de donnees, les applications, les progi- 
ciels, les objets distribues, les executables, etc. L'utilisation du diagramme 
de composants pour l'exploitation est illustre au chapitre 10. 
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Figure 2-10 : Diagramme de composants 

Le diagramme de deploiement correspond a la fois a la structure du reseau 
informatique qui prend en charge le systeme logiciel, et la fa5on dont les 
composants d'exploitation y sont installes. Vous trouverez aux chapitres 5 
et 10 l'utilisation d'un tel diagramme. 
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Figure 2-11 : Diagramme de deploiement 

Le mode de representation dynamique ou comportemental s'appuie sur les 6 
diagrammes ci-apres, dont 2 nouveaux diagrammes introduits par UML 2.0. 
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Figure 2-12 : Diagramme d'etats 

Le diagramme d'etats represente le cycle de vie commun aux objets d'une 
meme classe. Ce diagramme complete la connaissance des classes en ana- 
lyse et en conception. Le chapitre 8 vous indiquera comment utiliser ce 
diagramme a des fins d' analyse et le chapitre 11a des fins de conception. 
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Figure 2-13 : Diagramme d'activite 



Le diagramme d'activite represente les regies d'enchainement des activites 
et actions dans le systeme. II permet d'une part de consolider la specifica- 
tion d'un cas d'utilisation comme illustre au chapitre 4, d'autre part de 
concevoir une methode comme le montre le chapitre 1 1 . 
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Figure 2-14 : Diagramme de sequence 
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Les diagrammes de communication et de sequence sont tous deux des dia- 
grammes d' interactions UML. lis representent les echanges de messages 
entre objets, dans le cadre d'un fonctionnement particulier du systeme. Le 
diagramme de communication peut etre utilise de facon particuliere pour 
modeliser le contexte dynamique du systeme, tel qu'illustre au chapitre 3. 
Les diagrammes de sequence servent ensuite a developper en analyse les 
scenarios d' utilisation du systeme. Vous en trouverez des exemples au cha- 
pitre 8. Enfin, les diagrammes de communication permettent de concevoir 
les methodes comme indique au chapitre 11. 
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Figure 2-15: Diagramme de communication 

Le diagramme global d' interactions (overview interaction) a ete introduit 
par UML 2.0. II propose d'associer les notations du diagramme de 
sequence avec celles du diagramme d'activite. A ce titre, il peut etre aussi 
bien utilise en phase d' analyse qu'en phase de conception pour la descrip- 
tion d'une methode complexe. 
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Figure 2-16: Diagramme global d'interactions 



1. Note : le diagramme de communication d'UML 2 correspond au diagramme de collabo- 
ration precedemment connu dans les differentes versions d'UML 1. 
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Le diagramme de temps (timing diagram) temine cette liste des diagram- 
mes par un nouveau type de formalisme apporte par UML 2.0. Ce dernier 
provient de techniques connues de l'ingenierie systeme et repond a des 
besoins de modelisation tres specifiques lorsque F interaction entre plu- 
sieurs objets exige des contraintes temps-reel extremement precises et non 
equivoques. 
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Figure 2-17 : Diagramme de temps 



processus par niveaux d'abstraction 

La modelisation se construit forcement par etapes successives de plus en plus 
detaillees. II est en effet impossible de produire un modele representant quel- 
ques milliers de lignes de code sans passer par les etapes d'avancement qui 
permettent d'organiser judicieusement le volume d'informations collectees. 

Tout processus construit sur un modele doit done se doter d'une tactique 
d'avancement par consolidation de chaque etape de construction du modele. 
Un tel avancement est iteratif, car il definit des objectifs a atteindre suivant un 
decoupage en niveaux de detail allant croissant par rapport au modele de deve- 
loppement. Ces niveaux correspondent a une vision de moins en moins 
abstraite du developpement, e'est pourquoi nous les qualifions aussi de 
niveaux d'abstraction. 

Pour illustrer revolution du modele par niveaux d'abstraction, nous avons 
recours a un cone dont la surface symbolise a un instant donne le volume 
d'informations rassemblees par le modele. Le processus en Y implique une 
dichotomie initiale du modele suivant les deux branches fonctionnelle et tech- 
nique, comme l'illustre la figure 2-18. 
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Figure 2-18 : Les niveaux d 'abstraction du processus en Y 

Chaque niveau d' abstraction du modele s'inscrit dans une etape du processus 
et fixe un objectif de description du modele. 

Pour la capture des besoins fonctionnels : 

le niveau du contexte a pour objet de definir la frontiere fonctionnelle entre 
le systeme considere comme une boite noire et son environnement ; 

le niveau des cas d' utilisation definit ensuite les activites attendues des dif- 
ferents utilisateurs par rapport au systeme toujours envisage comme une 
boite noire. Ce modele permet de controler la bonne adequation des 
besoins avec les utilisateurs. 

Pour 1' analyse : 

on ouvre le systeme pour etablir la structure des objets utilises. Le modele 
d' analyse du domaine definit la structure et le comportement des objets 
connus dans le metier des utilisateurs du systeme ; 

le modele d' analyse de 1' application y rajoute, suivant le meme processus, 
les objets qui sont connus des utilisateurs, dans le cadre de la mise en 
application de leurs besoins. 

Pour la capture des besoins techniques : le modele d' analyse technique etablit 
des couches logicielles et y specifie les activites techniques attendues. 

Pour la conception generique : le modele de conception technique definit les 
composants qui, delivrant des services techniques, assurent la reponse aux 
exigences operationnelles du systeme. 

Pour la conception preliminaire : le modele de conception systeme organise le 
systeme en composants, delivrant les services techniques et fonctionnels. Ce 
modele regroupe les informations des branches fonctionnelle et technique. II 
peut etre considere comme la transformation du modele d' analyse par projec- 
tion des classes d' analyse sur les couches logicielles. 
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Pour la conception des classes : le modele de conception des composants 
fournit l'image « pret a fabriquer » du systeme complet. 

Notons que, prealablement au developpement, un modele metier peut etablir 
le contexte organisationnel dans lequel vient s'inserer le systeme informa- 
tique. Ce modele eventuellement objet constitue un point d' entree possible au 
processus enY. Mais nous n'aborderons pas la problematique de modelisation 
metier dans cet ouvrage. 

Une fois les objectifs etablis, l'avancement sur un modele se fait par itera- 
tion des memes taches de construction jusqu'a obtention d'un modele 
satisfaisant. Nous vous presenterons dans cet ouvrage le workflow de 
construction associe a chaque niveau d' abstraction. L' animation d'un 
processus iteratif consiste a planifier les taches necessaires a l'aboutisse- 
ment du modele, a les realiser, puis a valider le modele avec les acteurs 
concernes. 




Figure 2-19 : Animation du processus iteratif 



Les points de vue de modelisation 

Le processus en Y itere done sur la construction d'un modele. A cet effet, nous 
avons aborde les niveaux qui servent a fixer des jalons dans l'avancement du 
developpement. II nous reste maintenant a considerer les points de vue qu'un 
modele doit honorer ainsi que les techniques qu'il doit developper pour struc- 
turer le volume d' informations croissant qu'il contient. 

En tant que support d' etude, d' anticipation, de conception et de documenta- 
tion du systeme, le modele doit representer les points de vue necessaires aux 
differents protagonistes du developpement. Ces points de vue represented 
autant de vitrines d' observation du meme probleme en mettant en valeur 
certains contenus et en en masquant d'autres. Par analogie au BTP, pensez aux 
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plans traces pour les differents corps de metier, electricite, plomberie, macon- 
nerie, etc. Les points de vue du modele d'un systeme logiciel sont repertories 
ci-apres. 

Le point de vue de specification fonctionnelle concerne 1' organisation du 
modele des besoins fonctionnels exprimes par les utilisateurs et etudies 
par les analystes. Les elements de construction correspondent aux cas 
d' utilisation organises en packages, aux acteurs, aux activites, aux inte- 
ractions entre objets et aux contraintes dynamiques. 

Le point de vue structurel a trait a l'organisation du modele des besoins 
elabore en classes par les analystes. Les elements de construction y sont 
les categories, les classes, les associations, les generalisations, les attri- 
buts et les contraintes structurelles. 

Le point de vue materiel developpe la structure physique des machines et 
des reseaux sur lequel repose le systeme informatique. II concerne les 
ingenieurs systeme et reseau. Comme elements de construction, on 
compte les nceuds et les connexions qui permettent de prevoir le dimen- 
sionnement des processeurs et des bandes passantes. 

Le point de vue de deploiement represente la structure des postes de tra- 
vail et localise les composants sur le reseau physique. II concerne les 
ingenieurs d' exploitation charges d'installer le logiciel et d'identifier les 
causes de pannes. Les elements de construction y sont les postes de tra- 
vail, les serveurs, les connexions et les composants qui permettent d'etu- 
dier les echanges internes et externes du systeme en developpement. En 
client/serveur, on evoquera souvent les niveaux de repartition locale, 
departementale et centrale. 

Le point de vue d' exploitation correspond a l'organisation des compo- 
sants et identifie les fonctions prises en charge par le logiciel installe. II 
concerne a la fois les ingenieurs d' exploitation et les concepteurs, les uns 
pour trouver le composant incrimine par une panne, les autres pour car- 
tographier les dependances logicielles. Les composants, les interfaces et 
les dependances entre composants constituent les elements de construc- 
tion. En client/serveur, il est d'usage de repartir les composants suivants 
des architectures 2-tiers, 3-tiers ou n-tiers. 

Le point de vue de specification logicielle concerne les architectes qui 
decident de repartir par couches les exigences techniques, afin de les dis- 
socier par nature de responsabilites. Les elements de construction y sont 
les cas d'utilisation techniques organises en couches, les exploitants, les 
activites, les interactions entre objets et les contraintes dynamiques. On 
aura recours aux couches reparties en responsabilites de presentation, de 
gestion des applications, de gestion du metier, d'acces aux donnees et de 
stockage des donnees. 
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Le point de vue logique est relatif a F organisation du modele de solution 
elabore en classes par les concepteurs. Les elements de construction y sont 
les classes regroupees en categories, les interfaces, les associations, les 
generalisations, les realisations, les attributs, les etats, les operations et 
leurs methodes. Ce point de vue est incontournable, car il fournit la vision 
« pret a coder » de la solution et inversement, documente le code produit. 

Vous remarquez que tous les points de vue n'interviennent ni au meme 
moment, ni au meme niveau d' abstraction dans le processus de developpe- 
ment. II existe par ailleurs des dependances entre points de vue, dont il est 
necessaire d' avoir une cartographie pour maintenir la coherence du modele. 
La figure 2-20 presente les relations existant entre les differents points de vue 
et les situe par rapport aux differents niveaux d' abstraction du modele. 
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Figure 2-20 : Cartographie des points de vue de modelisation 

La specification fonctionnelle defend le point de vue des utilisateurs, elle 
pilote le contenu du developpement et conditionne les points de vue structurel 
et logique mais egalement le deploiement de la conception systeme de la 
facon suivante : 

les cas d' utilisation permettent de trouver les classes de la vue structurelle 
du modele d' analyse ; 

les scenarios elabores par cas d' utilisation permettent de trouver les opera- 
tions des interfaces de la vue logique du modele de conception systeme ; 

les cas d'utilisation identifient des fonctions qu'il faut repartir sur le 
deploiement du modele de conception systeme. 

La specification logicielle se place du point de vue des exploitants et gere le 
modele de la fa5on suivante : 

les cas d'utilisation techniques permettent de trouver les classes de la vue 
logique du modele de conception technique. Leurs scenarios permettent de 
trouver les operations de ces classes regroupees par couches ; 
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les cas d'utilisation techniques identifient les fonctions d' exploitation qu'il 
faut repartir sur le deploiement du modele de conception systeme. 

La vue du materiel presente le support du deploiement. 

La vue structurelle projette ses classes dans la vue logique au niveau de la 
conception systeme. 

La vue d'exploitation definit ses composants a partir des interfaces de la vue 
logique du modele de conception systeme et des composants de deploiement. 

Le tableau suivant etablit la correspondance entre les diagrammes proposes 
par UML 2 et les points de vue de modelisation. Le symbole V signifie que 
l'utilisation du diagramme est incontournable dans la formalisation du point 
de vue, tandis que •/ symbolise une utilisation optionnelle. 



Point de vue 
Diagramme UML 2 


Spec. 
Fonc. 


Struct. 


Spec. 
Log. 


Mat. 


Log. 


Expl. 


Depl. 


Conf. 
Log. 


Classes 




✓ 


y 




✓ 








Packages 




✓ 






✓ 








Objets 




y 






y 








Structure composite 




y 






y 








Cas d'utilisation 


✓ 




✓ 












Sequence 


✓ 




y 




✓ 








Collaboration 


✓ 




y 




✓ 








Etats 




✓ 






✓ 








De temps 










y 








Activite 


✓ 




✓ 




y 








Global d'interactions 


y 




y 




y 








Composants 












✓ 


✓ 


✓ 


Deploiement 








✓ 






✓ 





Tableau 2-2 : Utilisation des diagrammes UML 2 en fonction des points de vue du modele 



Un processus centre sur I'architecture 

Le terme architecture est un mot actuellement en vogue mais utilise de 
maniere abusive. L architecture est souvent mal comprise parce qu'on la situe 
dans la structure resultante d'un modele. L architecture n'est pas la conse- 
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quence du modele mais preside au contraire a son organisation. Cette organi- 
sation fixe des directives generates au developpement, et les structures qu'elle 
induit aident au maintien de l'integrite du modele. 



ARCHITECTURE 

L' architecture est Fensemble des decisions d'organisation du systeme logi- 
ciel qui defend les interets de son proprietaire final. Les interets s'expriment 
en termes d'exigences fonctionnelles, techniques et economiques. L' archi- 
tecture y repond par 1' integration de plusieurs styles de developpement 
informatique qu'elle adapte aux elements logiciels d'un contexte existant. 

Le proprietaire du systeme logiciel, par definition le maitre d'ouvrage, est au 
premier chef concerne par 1' adequation aux besoins des utilisateurs, la perti- 
nence par rapport a l'organisation de l'entreprise, l'analyse de la valeur qui en 
resulte, et les qualites de maintenance et d'evolution du logiciel. C'est pour- 
quoi 1' architecture du logiciel decrit plusieurs axes de solution generique, 
definis comme ci-apres. 

Les architectures client/serveur en tiers (2-tiers, 3-tiers ou n-tiers) concernent 
la capacite de montee en charge du systeme. Le style 2-tiers vise des applica- 
tions departementales a nombre limite d'utilisateurs. Elles mettent generale- 
ment en jeu des clients et un serveur de base de donnees. Les styles 3-tiers ou 
n-tiers permettent revolution du nombre des utilisateurs par l'introduction 
d'un middleware, qui distribue les services entre les clients et les serveurs. 

Les architectures en couches visent la distribution des responsabilites techni- 
ques sur les parties developpees pour le systeme logiciel. Nous avons deja cite 
la repartition suivant les cinq couches : presentation, application, metier, acces 
aux donnees et stockages des donnees. Ces architectures ameliorent les quali- 
tes d'evolution et de maintenance des aspects techniques du systeme. 

Les architectures en niveaux correspondent au deploiement des fonctions sur 
les postes de travail des utilisateurs. Les 3 niveaux considered pour l'entreprise 
sont le niveau central, le niveau departemental et le niveau local. Ces niveaux 
permettent de mieux controler l'imbrication des fonctions du systeme, ce qui 
ameliore ses qualites d'evolution et de maintenance fonctionnelles. 

Les architectures a base de composants consistent a developper les oppor- 
tunity de reutilisation au sein du systeme informatique. Les composants 
sont a la fois specifiquement developpes ou achetes sur etagere. Une telle 
architecture impose dans tous les cas une definition stricte de la 
decomposition modulaire. Les composants ameliorent non seulement les 
qualites d'evolution et de maintenance mais egalement les couts de deve- 
loppement du systeme. 



Definition 
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L' architecture implique des decisions d'organisation qui se repercutent sur la 
structure du modele lui-meme. Les differents points de vue de modelisation 
cites precedemment deviennent les outils de controle de Farchitecte logiciel 
qui permettent de superviser la conformite du developpement aux interets du 
maitre d'ouvrage. Le tableau suivant illustre l'influence des styles d'architec- 
ture sur les differents points de vue du modele. 



Architecture 
Points de vue 


Multiniveaux 


Par composant 


En couches 


Multitiers 


Specification 
fonctionnelle 


Positionnement des 
acteurs aux differents 
niveaux de I'entre- 
prise. 


Identification de cas 
d'utilisation geres par 
des composants exis- 
tants. 






Specification 
logicielle 




Identification de cas 
d'utilisation techni- 
ques, geres par des 
composants exis- 
tants. 


Positionnement des 
cas d'utilisation tech- 
niques sur les diffe- 
rentes couches. 




Structurel et 
organisationnel 


Regroupement des 
classes par niveau. 


Regroupement des 
classes provenantde 
composants exis- 
tants. 






Materiel 


Definition des mate- 
riels installes par 
niveaux. 






Definition d'un 
middleware. 


Deploiement 


Definition des pos- 
tes de travail par 
niveau. 


Identification et posi- 
tionnement des 
composants d'exploi- 
tation sur le reseau. 




Regroupement des 
composants par ser- 
vices distribues. 


Exploitation 


Regroupement des 
composants par 
poste de travail. 


Identification des 
interfaces et des 
composants a 
exploiter. 


Repartition des com- 
posants par couche. 


Repartition des 
composants entre 
tiers. 


Architecture 
Points de vue 


Multiniveaux 


Par composant 


En couches 


Multitiers 


Logique 




Regroupement des 
classes communes 
au meme composant. 


Identification des 
classes se situant 
dans la meme 
couche de services 
techniques. 


Identification des 
interfaces et des 
classes distributes. 


Configuration 
logicielle 




Fabrication de 
chaque composant. 


Fabrication des 
composants specifi- 
ques a une couche. 


Fabrication des 

composants 

distribues. 



Tableau 2-3 : Influence des styles d'architecture sur les vues du modele 
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Un processus centre sur 1' architecture impose le respect des decisions d' archi- 
tecture a chaque etape de construction du modele. L' architecture est done la 
condition qui preside a l'integrite d'un projet complexe, car elle permet la 
structure et la coherence des points de vue. 

La somme des parties d'un systeme complexe a en effet pour caracteristique 
de depasser la complexite de chacune des parties. L' organisation d'un modele 
coherent permet d'etablir des regies precises de croissance, sans depasser les 
capacites de comprehension humaine. L'architecte utilise la structure du 
modele pour communiquer et controler les liens complexes entre ces parties. 
Le processus centre sur 1' architecture permet done de degager des opportu- 
nity pour renforcer les interets economiques du maitre d'eeuvre : 

les modeles correctement organises offrent des moyens de reutilisation du 

logiciel a large echelle ; 

leur decoupage facilite l'elaboration de metriques, l'estimation et la 
repartition du travail entre equipes ; 

les points de vue coherents facilitent l'etude d'impact suivant les differents 
axes de changement que sont revolution des fonctions, de la structure des 
entites, des techniques, des configurations d'exploitation, et des versions 
logicielles ; 

la documentation apportee par les modeles facilite les tests, F integration, 
et aide a identifier la source des erreurs. 



Un processus oriente vers les composants 

Le respect des regies d' architecture et la structuration du modele a toutes les 
etapes du processus tend naturellement a regrouper les concepts a forte cohe- 
rence et a identifier scrupuleusement tous les couplages entre parties. 
L expression des couplages implique la specification de regies d' interface et 
permet d'evaluer l'opportunite de reutiliser les regroupements de concepts a 
d'autres contextes de developpement. 

Au niveau du systeme d' information d'entreprise, tel que celui presente dans 
l'etude de cas, un progiciel doit etre considere comme un composant a part 
entiere, ay ant des caracteristiques fonctionnelles et logicielles propres. Cette 
orientation rejoint clairement les options du « best of breed » qui vise a posi- 
tionner le meilleur outil a la meilleure place pour repondre aux fonctions du 
systeme d' information d'entreprise ; elle se distingue d'une philosophic 
« ERP centric » qui tend au contraire a ramener toutes les fonctions de l'entre- 
prise dans le meme progiciel. Le mariage de plus en plus frequent de progi- 
ciels du marche, de developpements specifiques et de technologies 
d' integration (EAI ou services Web) va introduire des contraintes non 



Chapitre 2 • Processus et architecture 



41 



negligeables dans l'organisation d'une modelisation UML tant pour les acti- 
vites d' analyse que pour celles de conception. 

Les regroupements de concepts definissent des packages et des composants 
dans le modele, leur reutilisation peut se situer a tous les niveaux d' abstrac- 
tion. De plus, la coherence du modele impose d'etablir et de suivre les liens 
entre les structures d'un point de vue a l'autre et d'une etape a 1' autre. 

Lors de la capture des besoins fonctionnels, les cas d'utilisation peuvent 
etre regroupes en packages pour organiser le modele de specification fonc- 
tionnel. Ces packages representent les besoins d'un metier d'entreprise 
vis-a-vis d'un systeme informatique, et peuvent constituer des modeles de 
specification a reutiliser par des progiciels metier. Les packages de cas 
d'utilisation structurent la repartition en applications du systeme. Ces 
applications deployees sur les postes de travail constituent une partie des 
composants du modele d' exploitation. 

Lors de F analyse, les classes sont regroupees en categories pour organiser 
successivement le modele d' analyse metier et le modele d' analyse de 
F application. Les categories metier representent la description detaillee des 
concepts de l'entreprise et peuvent constituer des references, reutilisables 
par differentes applications. Les categories d' analyse structurent les catego- 
ries de conception ainsi que la repartition en composants metier. Ces der- 
niers constituent eventuellement des composants du modele d'exploitation. 

Pour la capture des besoins techniques, les cas d'utilisation sont regroupes 
en couches logicielles en vue d' organiser le modele de specification tech- 
nique. Ces packages representent les besoins techniques vis-a-vis d'une 
technologie, et peuvent constituer des modeles de specification a reutiliser 
par differentes applications de l'entreprise. Les couches logicielles structu- 
rent la creation de frameworks techniques qui constituent des mecanismes 
de conception generique pour la technologie concernee. 

Lors de la conception preliminaire, les classes sont regroupees en fra- 
meworks pour remplir des fonctions techniques specifiques. Les fra- 
meworks constituent eventuellement des composants du modele 
d'exploitation et participent au modele de configuration logicielle. 

Pour la conception detaillee, les classes sont organisees en categories et docu- 
mentent generalement une librairie de classes reutilisables. Les categories de 
conception constituent eventuellement des composants du modele d'exploita- 
tion et structurent les sous-systemes de configuration logicielle. 

Les composants d'exploitation sont les elements que Ton deploie pour ins- 
taller le systeme complet. Les differentes technologies correspondant a 
cette notion sont les instances de bases de donnees, les applications a dis- 
position des utilisateurs, les librairies dynamiques, les objets distribues, les 
JavaBeans, etc. 
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Figure 2-21 : Positionnement et influence des structures 
reutilisables surle processus 2TUP 



Aujourd'hui, il existe des technologies orientees composant, a savoir CORBA, 
.Net, J2EE et plus recemment les infrastructures EAI et Web Services. De fait, 
le developpement et 1' integration de composants vont de pair et le travail du 
developpeur necessite un effort encore plus pousse vers le respect du style 
d' architecture oriente composant. Les types de composants que Ton peut 
reutiliser au sein de Fentreprise ou du commerce s'integrent a differents 
niveaux suivant leur nature. 

Les composants transverses correspondent aux outils offrant des fonction- 
nalites purement techniques. De tels outils s'integrent des la conception 
technique s'ils se presentent sous la forme d'une bibliotheque de code. 
Dans tous les cas, ils doivent etre considered suivant les points de vue du 
deploiement, de leur exploitation et de leur configuration logiciel. 

Les composants verticaux, ou compogiciels, apportent a la fois des fonc- 
tions metier et une architecture technique. Ils doivent d'une part se repre- 
senter sous la forme de classes et de services pour etre integres dans les 
points de vue dynamique et statique du modele d' analyse. Si leurs 
mecanismes d'interface ne sont pas standard, ils font d'autre part l'objet 
d'une couche logicielle a integrer dans la conception technique. Les com- 
pogiciels doivent ensuite etre considered suivant les points de vue du 
deploiement et de leur exploitation. 

Les progiciels apportent des fonctions metier, une architecture technique 
et des interfaces utilisateur. S'ils sont prevus pour fonctionner en complete 
autonomic, leur integration dans un systeme d' information existant 
requiert une etude fonctionnelle et technique analogue a F integration d'un 
compogiciel. Les progiciels ont par ailleurs leur propre deploiement et 
exploitation. 
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Les bus d'integration EAI et B2B apportent un framework d'echanges qui 
a des implications non negligeables sur les architectures technique et fonc- 
tionnelle. Ce domaine a fait l'objet d'un « Profile » particulier edite en 
fevrier 2002 par l'OMG. 



Resume du chapitre 



La famille des « Unified Process » constitue une trame commune pour inte- 
grer les meilleures pratiques de developpement. Un processus UP est iteratif et 
incremental, centre sur 1' architecture, conduit par les exigences des utilisa- 
teurs, pilote par les risques et oriente composants. Le processus 2TUP se situe 
dans cette lignee, en insistant sur la non-correlation initiale des aspects fonc- 
tionnel et technique. Les deux branches d' etude fusionnent ensuite pour la 
conception du systeme, ce qui donne la forme d'un processus de developpe- 
ment en Y. La dichotomie initiale permet a la fois de capitaliser la connais- 
sance metier sur la branche gauche et de reutiliser un savoir-faire technique 
sur la branche droite. 



UML est le langage de modelisation objet standard du 2TUP. Chacun des 13 
types de diagrammes d'UML 2 est en effet pertinent pour representer les 
etapes de developpement et les points de vue de modelisation preconises. 
2TUP est construit autour de la construction et du maintien d'un modele qui 
permet de controler 1' adequation du developpement aux regies d' architecture 
et qui favorise la conception d'un systeme oriente composants. 
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Figure 2-22 : Rappel des etapes et des points de vue du 2TUP 
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Objectifs du chapitre 

Ce chapitre va nous servir a poser les bases de la capture des besoins du 
systeme a realiser. 

Dans un premier temps, nous allons introduire l'etude de cas qui servira de fil 
conducteur tout au long du livre, en donnant une version textuelle preliminaire 
de son cahier des charges. 

Dans un second temps, nous commencerons a determiner les besoins fonc- 
tionnels en considerant le systeme comme une boite noire, afin d'etudier sa 
place dans le systeme metier plus global de l'entreprise. Apres avoir identifie 
les acteurs qui interagiront avec le systeme, nous developperons un premier 
modele UML de niveau contexte, pour pouvoir etablir precisement les fron- 
tieres fonctionnelles du systeme. 



Quand intervient l'etude 
preliminaire ? 

L'etude preliminaire (ou preetude) est la toute premiere etape de notre 
processus de developpement. Elle consiste a effectuer un premier reperage des 
besoins fonctionnels et operationnels, en utilisant principalement le texte, ou 
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des diagrammes tres simples. Elle prepare les activites plus formelles de 
capture des besoins fonctionnels (decrite au chapitre 4) et de capture des 
besoins techniques (decrite au chapitre 5). 



Etude prcliminaire 



f. 




Corvtraintes 
techniques 



Figure 3-1 : Situation de I'etude preliminaire dans 2TUP 



Elements mis en jeu 

Acteur, 
Stereotype, 

Contexte statique, diagramme de classes, 
Message, evenement, 

Contexte dynamique, diagramme de communication. 



1. On peut comparer cette etape a la phase d' inception du Processus Unifie, qui consiste a cadrer 
le projet et a definir son business case, en particulier en identifiant toutes les entites externes qui 
vont interagir avec le systeme, et en definissant la nature de cette interaction a haut niveau. Cepen- 
dant, pour simplifier la lecture du livre, nous n'introduisons le concept cle de cas d'utilisation que 
dans le chapitre suivant. 
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ETUDE DE CAS : PRESENTATION DU PROJET 

VExpress est une societe dont I'activite principale est la messagerie. Cette activite consiste en 
I'enlevement, le transport et la livraison de colis. 

VExpress possede 800 vehicules repartis sur 70 agences. La societe traite un volume moyen de 
40 000 colis par jour (enlevements et livraisons) et compte 3 000 employes. 

VExpress souhaite se doter d'un systeme informatique performant afin de : 

• maTtriser au plus pres I'acheminement des colis par la connaissance de leur localisation et 
de leur etat, 

• suivre la realisation des commandes, ainsi que la gestion comptable des factures et des 
reglements, 

• off rir aux clients la possibility de suivre I'acheminement de leurs colis via une connexion 
Internet. 

La duree de vie du nouveau systeme, appele SIVEx (Systeme d'lnformation de VExpress), est 
estimee a 5 ans. 



ETUDE DE CAS : GRANDS CHOIX TECHNIQUES 

Afin de maitriser les risques, VExpress souhaite utiliser une approche iterative et incrementale, 
fondee sur le processus en Y (decrit au chapitre 2). 

Apres une premiere etude menee par un cabinet-conseil, la direction generale de VExpress a 
officialise le choix d'un certain nombre de techniques cles pour ce projet strategique, et donne 
son feu vert a un vaste plan de formation des informaticiens de la societe. 

Ces technologies cles sont principalement : 

• la moderation objet avec UML, 

• les architectures 3-tiers avec SGBDR, 

• le deploiement en client leger pour les fonctions les plus repandues, 

• le deploiement en client lourd pour certaines fonctions d'administration necessitant une 
ergonomie particuliere, 

• la plate-forme Java (avec JSP et Struts, Swing, EJB et JDBC) et les potentialites de XML pour 
les applications a developper, 

• le deploiement de SAP R/3 pour les modules comptables et ventes (CO & SD), 

• le deploiement d'une solution CRM fondee sur le progiciel SIEBEL. 

Autre point crucial, la direction de VExpress est tres sensible a la problematique de I'EAI (Enter- 
prise Application Integration) et souhaite integrer au maximum le nouveau systeme informatique 
aux briques existantes du systeme d'information de la societe. 

Le positionnement respectif de tous ces elements techniques est illustre a la figure suivante. 
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Figure 3-2. : Architecture logicielle preliminaire 



ETUDE t>E CAS : RECUEIL DES BESOINS FONCTIONNELS 

Un premier tour d'horizon des besoins exprimes par les employes de I'entreprise a permis d'eta- 
blir le cahier des charges preliminaire suivant : 

Traitement des commandes 



Les commandes sont saisies dans le progiciel Siebel par un receptionniste a partir des informa- 
tions fournies par les clients. Lors de la prise de commande, le receptionniste doit disposer du 
cout estime de la prestation et des dates probables d'enlevement et de livraison. Ces informa- 
tions doivent pouvoir etre editees et envoyees directement par fax ou courrier electronique au 
client. 

Lors d'une premiere prise de commande, le receptionniste doit enregistrer les caracteristiques 
du nouveau client egalement dans Siebel ; les donnees des commandes et des clients sont auto- 
matiquement synchronisers avec SAP pour leur suivi en back-office. 

Une fois confirmees, les commandes sont mises a disposition immediate du service administratif 
et des agences chargees du transport. Ces informations portent principalement sur I'adresse 
d'enlevement, I'adresse de livraison et la description de chaque colis. 

Un en-cours de commande est ensuite maintenu a jour par le systeme. II precise la localisation 
des colis de la commande, ainsi que les dates d'enlevement et de livraison. Le receptionniste, ou 
le client lui-meme via Internet, est par la suite a meme de consulter ces informations de suivi. 
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Les factures des commandes realisees et leur consolidation journaliere sont transmises au progi- 
ciel SAP. 

Un comptable emet les factures des clients qui reglent leurs commandes en differe. Par ailleurs, 
il saisit les differents reglements recus et les repartit sur les factures. 

Le systeme peut editer les lettres de relance pour les factures non payees en fonction de criteres 
dependant du client (delai et/ou decouvert autorise). Le systeme permet ainsi au comptable de 
suivre ses contentieux de paiement. 

Creation de mission 



Un repartiteur cree les missions d'acheminement pour son agence. Une mission traite un ensem- 
ble de commandes qui transitent par I'agence. A cet effet, le repartiteur definit I'ordre des etapes 
(points de passage pour enlever ou livrer les commandes), puis affecte a la mission un vehicule 
et un chauffeur. 

Le repartiteur s'appuie sur les ressources (vehicules et chauffeurs) dont il dispose a son agence. 
Le cas echeant, il peut utiliser temporairement des ressources d'une autre agence deleguees par 
le responsable logistique. 

On distingue trois types de missions : I'enlevement de colis, leur livraison et le convoyage entre 
deux agences (traction). 

Suivi de mission 



Un chauffeur part en tournee avec les bordereaux decrivant les commandes a livrer sur les diffe- 
rents sites de chaque etape de la mission. II est equipe d'un terminal portable lui permettant 
d'indiquer en temps reel I'etat de sa mission : les arrets et les departs aux differentes etapes, les 
acquittements des clients, ainsi que les incidents occasionnels qu'il peut rencontrer (panne, 
retard, refus de reglement, absence du client...). 

Un systeme de localisation (GPS pour I'instant, mais avec une migration vers Galileo des que 
celui-ci sera disponible) est embarque dans chaque vehicule et permet d'envoyer automatique- 
ment et periodiquement (toutes les quinze minutes) sa position au systeme, pendant toute la 
duree de la mission. 

Des qu'une mission se deroule de facon anormale, le systeme doit en avertir immediatement le 
repartiteur. 

Traitement des colis 



Au retour d'une mission d'enlevement, un operateur de quai identifie les colis a partir de la liste 
etablie pour chaque commande. A I'aide d'une bascule reliee au systeme, les colis sont peses 
afin de verifier les depassements tarifaires de charge. Une etiquette a code-barre, imprimee par 
le systeme est alors collee sur le colis par I'operateur de quai. 

Chaque fois qu'un colis transite sur un quai (depart de livraison, depart ou arrivee de traction), un 
operateur de quai pointe I'etiquette du colis afin de permettre sa localisation en temps reel. 

Les operateurs de quai doivent egalement disposer d'un mode « inventaire » qui leur permet de 
pointer tous les colis presents sur le quai et de detecter les colis oublies (presents sur le quai 
depuis plus de48 h). 
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Logistique 



Le responsable logistique doit effectuer les taches suivantes : 

• il definit la liste des agences et des ressources (vehicules et chauffeurs) ainsi que la 
repartition de ces ressources entre les agences ; 

• il definit differents plans de transport. Chacun de ces plans se compose des zones de redis- 
tribution et des zones terminales des agences, ainsi que des connexions a appliquer pour 
I'acheminement des commandes. Un seul plan de transport est applicable a un instant 
donne pour I'ensemble du reseau ; 

• enfin, le responsable logistique consulte regulierement les statistiques de transport (frequen- 
tations, accidents, retards, et ce par site, par agence et par region), afin d'optimiser ses 
plans de transport. 



ETUDE DE CAS : RECUEIL DES BESOINS OPERATIONNELS 

Securite 

Lors de sa connexion, chaque employe doit etre reconnu du systeme par un nom, un mot de 
passe et la fonction qu'il occupe (par agence). 

Un client connecte via Internet doit egalement etre identifie par un mot de passe et n'acceder 
qu'aux informations d'en-cours de commande qui le concernent. 

Un administrateur systeme est charge de definir les profils des utilisateurs. 
Volume de donnees 

Certaines donnees du systeme doivent etre traitees en temps reel : le suivi de I'etat courant des 
missions, celui des incidents, la creation et la modification des commandes. 

D'autres donnees peuvent faire I'objet de traitement « batch » : edition journaliere des factura- 
tions, suivi statistique de I'activite. 

Une premiere evaluation du volume de donnees a produit les resultats suivants : 



Type de donnees 


Volume unitaire 
(Ko) 


Quantite 
(par mois) 


Dureede retention 
(mois) 


Volume total (Mo) 


Commande 


0,5 


300 000 


6 


9 000 


Facture 


0,5 


200 000 


6 


6 000 


Historique evenements 


0,1 


900 000 


6 


540 


Colis 


0,2 


1 200 000 


6 


1 440 


Bordereau 


1 


46 000 


6 


276 


Mission 


0,5 


46 000 


6 


138 


Inventaire 


4 000 


100 


6 


2 400 


Donnees d'exploitation 


19 764 



Tableau 3-1 : Volume de donnees d'exploitation 
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Type de donnees 


Volume unitaire (Ko) 


Quantite 


Volume total (Mo) 


Client 


1 


30 000 


30 


Plan de transport 


1 000 


4 


4 


Vehicule 


1 


800 


0,8 


Employe 


0,1 


3 000 


0,3 


Donnees statiques 






35,1 



Tableau 3-2 : Volume de donnees de base 



Une fois ce premier recueil de besoins effectue, la description du contexte du 
systeme peut commencer. Elle consiste en trois activites successives : 

1' identification des acteurs, 

1' identification des messages, 

la realisation des diagrammes de contexte. 

Identifier les acteurs 



QU'EST-CE QU'UN ACTEUR ? 

"onseil ^ n acteur represente 1' abstraction d'un role joue par des entites externes 
(utilisateur, dispositif materiel ou autre systeme) qui interagissent directe- 
ment avec le systeme etudie. 

Un acteur peut consulter et/ou modifier directement l'etat du systeme, en 
emettant et/ou en recevant des messages eventuellement porteurs de donnees. 

Les acteurs candidats sont systematiquement : 

les utilisateurs humains directs : identifiez tous les profils possibles, sans 

oublier Fadministrateur, l'operateur de maintenance, etc. ; 

les autres systemes connexes qui interagissent aussi directement avec le 

systeme. 

Verifiez que les acteurs communiquent bien directement avec le systeme, par 
emission et/ou reception de messages. Une erreur frequente consiste a reperto- 
rier en tant qu' acteurs des entites externes qui n'interagissent pas directement 
avec le systeme, mais uniquement par le biais d'un des veritables acteurs. 

Verifiez que les acteurs se trouvent bien a I 'exterieur du systeme ! Une erreur 
frequente consiste a repertorier des acteurs qui correspondent en fait a des 
composants du systeme etudie, voire meme a de futures classes... 
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Dans notre etude de cas, nous consideions que SAP et Siebel sont des sous- 
systemes de SIVEx, c'est pourquoi ils n'apparaitront pas dans la liste des acteurs. 



ACTEUR : NE CONFONDEZ PAS ROLE ET ENTITE CONCRETE ! 

Une meme entite exteme concrete peut jouer successivement differents roles par 
rapport au systeme etudie, et par consequent etre modelisee par plusieurs 
acteurs. Reciproquement, le meme role peut etre joue simultanement par plu- 
sieurs entites externes concretes, qui seront alors modelisees par le meme acteur. 

Par exemple, face au systeme que constitue Fordinateur d'une salle de forma- 
tion, l'administrateur systeme va d'abord jouer son role habituel, pour installer 
une nouvelle version d'un outil UML ; puis, il va se connecter en tant que sim- 
ple utilisateur, afin de verifier que les stagiaires y auront bien acces lors de la 
prochaine session. II n'y a dans ce cas qu'une seule instance d' entite exteme 
concrete (l'administrateur systeme) et pourtant deux acteurs distincts... 



ETUDE DE CAS : ACTEURS DU SYSTEME SIVEX 

O Receptionniste : 

Le receptionniste a pour mission de saisir, et eventuellement d'annuler, les commandes en prove- 
nance des clients. 

O Client : 

Le client peut consulter ses en-cours de commande par Internet. II recoit egalement les confir- 
mations de commande par courrier electronique ou par fax. 

O Comptable : 

Le comptable fait le point regulierement sur les commandes, etablit les factures et avoirs des 
clients. II s'assure aussi du recouvrement des factures. 

O Repartiteur : 

Le repartiteur cree les differentes missions en fonction des commandes et des ressources dispo- 
nibles. II surveille les missions en cours de maniere a parer aux incidents. 

O Chauffeur : 

Le chauffeur assure les missions ; il receptionne ou livre les colis et avertit le systeme des arrets 
qu'il effectue a chaque etape. 

O Vehicule : 

Le vehicule envoie automatiquement et periodiquement sa position au systeme par le biais de 
son systeme de localisation embarque. 

O Operateur de quai : 

Loperateur de quai identifie et pese les colis provenant d'un enlevement. II pointe ensuite le 
passage des colis en depart et arrivee d'agence ou procede aux inventaires de quai. 
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O Responsable logistique : 

Le responsable logistique definit le reseau des agences et maintient la strategie de transport. 

O Administrateur systeme : 

L'administrateur systeme gere les profils des utilisateurs et les mots de passe. 



c 
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ELIMINEZ LES ACTEURS « PHYSIQUES » AU PROFIT DES « LOGIQUES » 

L'acteur est celui qui beneficie de l'utilisation du systeme. II a une autono- 
mic de decision. Cela ne doit pas se reduire a un simple dispositif mecanique 
passif. 

Par exemple, il serait peu judicieux de considerer comme acteurs pour 
SIVEx: 

les terminaux informatiques (ecrans, claviers, imprimantes, etc.) des diffe- 
rents employes de VExpress, a la place des differents profils identifies, 
la bascule de pesee au lieu de l'operateur de quai. 

Cette regie simple permet de s'affranchir dans un premier temps des technolo- 
gies d' interface et de se concentrer sur les acteurs « metier », nettement plus 
stables. 

ACTEUR = METACLASSE A PART ENTIERE 



Dans le metamodele 1 d'UML 2, le concept d'acteur est en fait une meta- 
classe a part entiere, avec une representation graphique standard. 

Cependant, comme cette metaclasse herite du concept plus abstrait de classi- 
fier (au meme titre que la classe), on peut montrer un acteur soit sous la 
forme graphique dite du stick man, soit sous une forme rectangulaire, avec le 
mot-cle «actor» : 



«actor» 
Vehicule 



Stick man 




Client 



Figure 3-3 : Representations graphiques possibles d'un acteur 

Une recommandation de plus en plus repandue consiste a utiliser le stick 
man pour les acteurs humains et la forme rectangulaire pour les acteurs non- 
humains, si l'outil de modelisation le permet. . . 



l.Le metamodele UML est une representation formelle sous forme de diagrammes de classes 
UML des elements de modelisation UML, tels que classe, package, message, acteur, etc. 
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Un acteur peut ainsi disposer : 

d'un ensemble d'attributs permettant de caracteriser son etat, 
d'un ensemble de signaux qu'il peut emettre ou recevoir, 
d'un diagramme d'etats. 



a VOUS POUVEZ STEREOT/PER LES ACTEURS ! 

. II est possible d'utiliser les mecanismes d'extensibilite d'UML pour stereo- 
typer le concept d' acteur afin de fournir des icones particulieres plus signifi- 
catives pour le lecteur. 

Pour distinguer visuellement les utilisateurs « humains » des acteurs « non- 
humains » dans les diagrammes de cas d'utilisation, et les diagrammes d'interac- 
tions, nous avons experimente avec succes la representation graphique suivante : 

X 

Vehicule 

Figure 3-4 : Proposition de stereotype d'acteur « non-humain » 



Identifier les messages 



QU'EST-CE QU'UN MESSAGE ? 

Un message represente la specification d'une communication unidirectionnelle 
entre objets qui transporte de Finformation avec Fintention de declencher une 
activite chez le recepteur. 

Un message est normalement associe a deux occurrences d'evenements : un eve- 
nement d' envoi et un evenement de reception. 

Cette notion de message est egalement tout a fait applicable pour decrire les 
interactions de plus haut niveau entre les acteurs et le systeme. 

Pour chaque acteur, demandez-vous quels sont les messages qui declenchent 
un comportement du systeme attendu par 1' acteur dans le cadre de son acti- 
vite. 
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Pour le systeme, demandez-vous quels sont les messages emis a F intention d'un 
acteur particulier, et qui portent une information utilisee par ce destinataire. 



ETUDE DE CAS : EXEMPLES DE MESSAGES ENTRE SIVEX 
ET SES ACTEURS 

Le systeme SIVEx emet (entre autres) : 

• les statistiques de transport pour le responsable logistique, 

• les confirmations de commande pour le client, 

• les incidents de mission pour le repartiteur. 
Le systeme SIVEx regoit (entre autres) : 

• les creations, modifications, ou annulations de commande du receptionniste, 

• les reglements de facture du comptable, 

• les creations de mission du repartiteur, 

• les informations de suivi de mission du chauffeur, 

• les positions des vehicules, 

• I'identification et le pointage des colis de I'operateur de quai. 



PAS DE MESSAGES ENTRE ACTEURS ! 

Ne perdez pas de temps a refiechir aux messages echanges par les acteurs : 
c'est generalement hors sujet par rapport au systeme etudie (sauf si vous 
modelisez le metier de l'entreprise et non un systeme informatique). 

Modeliser le contexte 

Tous les messages (systeme «-> acteurs) identifies precedemment peuvent etre 
represented de facon synthetique sur un diagramme, que Ton peut qualifier de 
diagramme de contexte dynamique. 

REPRESENTEZ LE CONTEXTE DYNAMIQUE GRACE A UN DIAGRAMME 
DE COMMUNICATION ! 

Utilisez un diagramme de communication de la facon suivante : 

le systeme etudie est represente par un participant central ; 
ce participant central est entoure par d' autres participants symbolisant les 
differents acteurs ; 

des liens relient le systeme a chacun des acteurs ; 

sur chaque lien sont montres les messages en entree et en sortie du 
systeme, sans numerotation. 
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De nombreux auteurs, comme G. Booch lui-meme dans Object Solutions 
[Booch 96], ou ensuite B. Douglass dans Real-Time UML [Douglass 04], ont 
preconise cette utilisation un peu particuliere du diagramme de communica- 
tion. 




Figure 3-5 : Diagramme de contexte dynamique de SIVEx 

Pour ne pas surcharger ce premier diagramme, nous avons volontairement omis : 

• les actions de consultation pure, sans effet de bord (ex : consultation des en-cours par le 
client ou le receptionniste), 

• les actions de connexion/deconnexion au systeme. 



© 
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DECRIVEZ LES MESSAGES TEXTUELLEMENT ! 



Afin de ne pas surcharger inutilement le diagramme de contexte, il est souvent 
necessaire de decrire a part, sous forme textuelle, le contenu des messages. 
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A cette etape, il est egalement possible de distinguer - si cela est pertinent 
pour comprendre l'usage metier du systeme - les messages asynchrones des 
messages synchrones, ainsi que de signaler les messages periodiques. 



ETUDE DE CAS : EXEMPLES DE DESCRIPTION DETAILLEE 
DE MESSAGES 

conditions commande : ce message est emis systematiquement par SIVEx en reponse a 
une creation ou une modification de commande effectuee par le receptionniste. II con- 
tient en particulier le cout estime de la prestation, ainsi que les dates prevues d'enleve- 
ment et de livraison. 

creation mission : ce message emis par le repartiteur lors de la creation d'une nouvelle 
mission contient les donnees suivantes : type de mission, liste des etapes, commandes 
concernees, chauffeur et vehicule affectes, dates prevues de depart et d'arrivee. 



EXPRIMER LE CONTEXTE STATIQUE 

On peut completer le modele de contexte dynamique par 1' etude du contexte 
statique. Ce dernier specifie le nombre d'instances d'acteurs reliees au sys- 
teme a un moment donne. 

Ce complement est surtout utile lorsque les acteurs sont nombreux, et que Ton 
veut mettre en evidence les differences qui existent en termes de multiplicites 
d'instances d'acteurs. On pourra ainsi exprimer que le systeme SIVEx peut 
etre relie simultanement a un nombre variable de clients qui consultent leurs 
en-cours par Internet, mais a un seul responsable logistique. 

Tout comme le diagramme de contexte dynamique peut etre realise au moyen 
d'un diagramme de communication UML, le diagramme de contexte statique 
peut etre dessine au moyen d'un diagramme de classes ne faisant intervenir 
que les acteurs et le systeme. 



ETUDE DE CAS : MODELE DE CONTEXTE STATIQUE 

Ce diagramme permet de montrer de fagon synthetique qu'il existe : 

• un seul responsable logistique, comptable et administrateur systeme dans la societe, 

• au maximum autant de repartiteurs que d'agences (70), 

• un maximum de 800 vehicules, 

• un nombre non defini de clients, receptionnistes, chauffeurs et operateurs de quai. 
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Vehicle Chauffeur qUS * 

Figure 3-6 : Diagramme de contexte statique de SIVEx 
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LE MODELE DE CONTEXTE STATIQUE N'EST PAS OBLIGATOIRE ! 

Ne perdez pas de temps a dessiner un diagramme representant un contexte 
statique qui ne montrerait que des multiplicites indefinies (0..*), ou au 
contraire un seul acteur avec une multiplicite 0..1 ! 




EXPRIMER LA DECOMPOSITION EN SYSTEMES FONCTIONNELS AU NIVEAU 
DU CONTEXTE 



Dans le cas de systemes complexes dont les grands sous-systemes fonction- 
nels sont deja connus, nous avons experimente avec succes une approche 
[Roques 99] qui consiste a : 

elaborer le modele de contexte dynamique du systeme, comme prece- 
demment ; 

traiter le systeme comme un participant composite contenant les dif- 
ferents sous-systemes fonctionnels grace a une inclusion graphique ; 
repartir les flots de messages du niveau systeme entre les sous-systemes 
concernes ; 

ajouter les principaux flots de messages entre les sous-systemes deux a 
deux. 
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Appliquee a notre etude de cas, l'approche consiste a considerer SIVEx 
comme un systeme composite constitue des progiciels Siebel et SAP et d'une 
partie a developper nommee « SIVEx central ». Voici un exemple partiel de 
diagramme de contexte dynamique ainsi decompose : 




Receptionniste : Client : Comptable 





confirmation ^ j 


reglements 




\ SIVEx / 

SIVEx central 

commande S \. fin mission 

JZs ... ^IC 




Siebel 




SAP R/3 






A paye 





Figure 3-7 : Modele de contexte dynamique decompose 



Ce diagramme de contexte « hierarchique » permet d'extraire facilement les 
trois modeles de contexte des sous-systemes. Chacun de ces sous-systemes 
pourrait a son tour etre decompose. 

II est a noter qu'UML 2 a defini le concept de « classe structuree », permettant 
a certaines classes complexes de posseder une structure interne et des points 
d'interaction appeles ports. On pourrait ainsi representer le systeme SIVEx 
par un diagramme de structure composite. 



SIVEx 



tSiebel 



<— — -<J 



: SIVEx central 



< £ 



:SAP R/3 



O 

Gestion 
commandes 



o 

Gestion missions, 
logistique, etc. 



<----6 



— o 

Comptabilitc 



Figure 3-8 : Diagramme de structure composite simplifie de SIVEx 
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Phases de realisation de 
I'etude preliminaire 



L' etude preliminaire a pour objectifs principaux de : 

etablir un recueil initial des besoins fonctionnels et operationnels, 
modeliser le contexte du systeme, considere comme une boite noire, en 

- identifiant les entites externes au systeme qui interagissent directement 
avec lui (acteurs), 

- repertoriant les interactions (emission/reception de messages) entre ces 
acteurs et le systeme, 

- representant F ensemble des interactions sur un modele de contexte 
dynamique, eventuellement complete par un modele de contexte sta- 
tique. 



Interviews, 
preetude 




charges 
preliminaires 




Acteurs 



Messages 



Modele de 
contexte 
dynamique 



Figure 3-9 : Resume des activites et des produits de I'etude preliminaire 



Chapitre Capture des besoins 
A fonctionnels 



Objectifs du chapitre 

Ce chapitre traite du role que tient UML pour completer la capture des besoins 
fonctionnels ebauchee durant Fetude preliminaire. La technique des cas 
d' utilisation est la pierre angulaire de cette etape. Elle va nous permettre de 
preciser 1' etude du contexte fonctionnel du systeme, en decrivant les diffe- 
rentes facons qu'auront les acteurs d'utiliser le futur systeme. 

Nous verrons successivement dans ce chapitre comment : 
identifier les cas d' utilisation du systeme par ses acteurs, 
decrire les cas d' utilisation, 
organiser les cas d' utilisation, 

identifier les classes candidates du modele d' analyse. 



Quand intervient la capture 
des besoins fonctionnels ? 

La capture des besoins fonctionnels est la premiere etape de la branche gauche 
du cycle en Y. Elle formalise et detaille ce qui a ete ebauche au cours de 
l'etude preliminaire. 

Elle est completee au niveau de la branche droite du Y par la capture des 
besoins techniques (decrite au chapitre 5) et prepare 1' etape suivante de la 
branche gauche : F analyse (decrite dans les chapitres 6 a 8). 
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Contraintes 
fonctlonnelles 



Etude pr 

■v Rranche t 

fomtionmlle I 

r — r x / , 



Etude preliminaire 



Bronchi 
technique 



Cu d'utilisation 



f 

Capture des besoins - 


~~ jL Capture des besoins 


fonctionnels 


techniques 



Specification 
fonctionnelle 




Figure 4-1 : Situation de la capture des besoins fonctionnels dans 2TUP 



Elements mis en jeu 

Messages, acteurs, modele de contexte dynamique. 
Acteur principal, acteur secondaire. 

Cas d' utilisation, description preliminaire d'un cas d' utilisation. 
Diagramme de cas d' utilisation. 

• Fiche de description textuelle d'un cas d' utilisation. 
Scenario, enchainement, diagramme d'activite. 
Diagramme de sequence. 

• Inclusion, extension et generalisation de cas d'utilisation. 
Package de cas d'utilisation. 

Classes candidates, responsabilites, diagramme de classes participantes. 
Tracabilite des cas d'utilisation avec les besoins fonctionnels, iteration. 

Identifier les cas d'utilisation 



QU'EST-CE QU'UN CAS D'UTILISATION ? 

Un cas d'utilisation (use case) represente un ensemble de sequences 
d' actions realisees par le systeme et produisant un resultat observable inte- 
ressant pour un acteur particulier. 

Un cas d'utilisation modelise un service rendu par le systeme. II exprime les 
interactions acteurs/systeme et apporte une valeur ajoutee « notable » a 
F acteur concerne. 
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Chaque cas d' utilisation specifie un comportement attendu du systeme consi- 
dere comme un tout, sans imposer le mode de realisation de ce comportement. 
II permet de decrire ce que le futur systeme devra faire, sans specifier 
comment il le fera. Dans le cadre de la branche fonctionnelle, le cas d' utilisa- 
tion doit mettre en valeur les interactions metier entre les acteurs et le 
systeme. On exprimera done des actions effectuees dans le cadre du metier de 
l'utilisateur, par opposition a des manipulations de 1' application ou a des 
comportements techniques. Par exemple, on ne developpe ni la manipulation 
d'une IHM (Interface Homme Machine), ni la gestion d'erreurs materielles au 
travers d'un cas d' utilisation. 

L'objectif est le suivant : l'ensemble des cas d'utilisation doit decrire exhausti- 
vement les exigences fonctionnelles du systeme. Chaque cas d'utilisation 
correspond done a une fonction metier du systeme, selon le point de vue d'un 
de ses acteurs. 

Pour chaque acteur identifie durant 1' etude preliminaire, il convient de : 

rechercher les differentes intentions metier avec lesquelles il utilise le sys- 
teme, 

determiner dans le cahier des charges les services fonctionnels attendus du 
systeme. 

On se servira avec profit des echanges de messages identifies dans le modele 
de contexte dynamique. 

Pour chaque cas d'utilisation candidat, il faut : 

verifier qu'il fournit une valeur ajoutee « notable » a l'acteur, toujours 
dans le cadre de son metier, 

controler qu'un evenement externe au systeme en declenche l'execution 
(sauf exceptionnellement pour des traitements « batch », comme la trans- 
mission comptable vers SAP). 



UN CAS D'UTILISATION NEST NI UNE TRANSACTION, 
NI UNE FONCTION ! 

Une erreur frequente concernant les cas d'utilisation consiste a vouloir des- 
cendre trop bas en termes de granularite, notamment lorsque Ton oublie la 
valeur metier d'un cas d'utilisation, par opposition aux transactions informa- 
tiques produites dans le cadre de la realisation d'une fonction de l'entreprise. 
Un cas d'utilisation represente un ensemble de sequences d' actions realisees 
par le systeme, et le lien entre ces sequences d' actions est precisement 
l'intention fonctionnelle de l'acteur vis-a-vis du systeme. Le cas d'utilisation 
ne doit done pas se reduire systematiquement a une seule sequence, et encore 
moins a une simple action. 
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Pour illustrer notre propos, considerez le travail d'un comptable desirant saisir 
les reglements qu'il a re9us. Son intention est de proceder a la saisie de ces 
reglements, et il pourra opter entre scanner des cheques, taper manuellement 
les versements ou saisir une feuille de depot de banque. Les trois options 
donneront lieu a des sequences d' actions differentes du meme cas d' utilisa- 
tion, car la valeur ajoutee est toujours identique dans le metier du comptable. 
Par ailleurs, le cas d'utilisation comprendra egalement des deroulements alter- 
natifs ainsi que la gestion de cas d'erreurs, comme nous allons vous le montrer 
en detail dans ce chapitre. 



a DISTINGUEZ L'ACTEUR PRINCIPAL DES ACTEURS SECONDAIRES ! 

'"onseil Nous appelons acteur principal celui pour qui le cas d'utilisation produit la 
plus-value metier. En consequence, F acteur principal est la plupart du temps 
(mais pas forcement, comme dans le cas precite des traitements batch) le 
declencheur du cas d'utilisation. Par opposition, nous qualifions d'acteurs 
secondaires les autres participants du cas d'utilisation. Les acteurs secondai- 
res sont typiquement sollicites a leur tour par le systeme pour obtenir des 
informations complementaires. 

Un cas d'utilisation comporte done : 
un acteur principal (e'est obligatoire), 
d'eventuels acteurs secondaires. 



NOMMEZ LES CAS D'UTILISATION AVEC UN VERBE A LTNFINITIF SUIVI 
D'UN COMPLEMENT ! 

Une recommandation complementaire consiste a veiller a bien utiliser le 
point de vue de 1' acteur et non pas celui du systeme. Par exemple, le cas 
d'utilisation d'un distributeur de billets par l'acteur « Porteur de CB » doit 
etre intitule « Retirer de 1' argent » (point de vue de l'acteur), et non « Distri- 
buer de 1' argent » (point de vue du systeme). 
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ETUDE DE CAS : LISTE PRELIMINAIRE DES CAS D" UTILISATION 
DE SIVEX 

Voici la technique recommandee pour identifier les cas d'utilisation a partir du modele de con- 
texte : considerez I'intention fonctionnelle de l'acteur par rapport au systeme dans le cadre de 
remission ou de la reception de chaque message (voir chapitre 3, figure 3-5). En regroupant les 
intentions fonctionnelles en unites coherentes, vous obtiendrez les cas d'utilisation recherches. 
Le tableau ci-dessous permet d'etablir le resultat de ce travail, en montrant le lien entre les cas 
d'utilisation identifies, les acteurs principaux et secondaires, et les messages provenant du con- 
texte. 
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Cas d'utilisation 


Acteur principal, 

dCleUlb bcOOnOdllcb 


Message(s) em is / recus 

nor lac 3/*taiii*c 
pal Icb dCleUlb 


Traitsr une commande 


Receptionniste 


emet '. creation, modification, annulation 
commande 

regoit : conditions commande 


Client 


regoit : confirmation commande 


Gerer les infos clients 


Receptionniste 


emet : creation client 


Consulter les en-cours 


Client 


regoit : en-cours 


Receptionniste 


regoit : en-cours 


Gerer la facturation 


Comptable 


regoit : factures 


Suivre les reglements 
Comptable 


emet : reglement 


regoit : relance 


Planifier une mission 


Repartiteur 


emet : creation, modification mission 


Chauffeur 


regoit : bordereaux mission 


Suivre une mission 


Chauffeur 


emet : arret/depart etape, evenement mission 


Repartiteur 


regoit : incident mission 


Vehicule 


emet : position 


Realiser I'inventaire 


Operateur de quai 


emet '. debut/fin inventaire, pointage colis 


Manipuler les colis 


Operateur de quai 


emet : pointage colis, identification colis 
regoit : listes colis commande, etiquette 


Definir le plan de transport 


Responsable logistique 


emet : creation, modification plan 
regoit : statistiques transport 


Gerer les ressources 


Responsable logistique 


emet : affectation ressources 


Gerer les profils 


Administrateur 


emet : profil utilisateur 



Tableau 4-3 : Liste des acteurs et des messages par cas d'utilisation 



ETABLISSEZ UNE PREMIERE DESCRIPTION SUCCINCTE DE CHAQUE CAS 
D'UTILISATION CANDIDAT ! 

Chaque cas d'utilisation doit faire Fobjet d'une definition a priori qui decrit 
F intention de 1' acteur lorsqu'il utilise le systeme et les sequences d' actions 
principales qu'il est susceptible d'effectuer. Ces definitions servent a fixer 
les idees lors de 1' identification des cas d'utilisation et n'ont aucun caractere 
exhaustif. 
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EXEMPLES DE DESCRIPTION PRELIMINAIRE DE CAS 



Planifier une mission (Repartiteur) : 



O Intention : planifier au sein d'une agence une mission necessaire a la realisation des 
commandes en cours ; 

O Actions : creer une nouvelle mission (regrouper des commandes, affecter des res- 
sources disponibles, etablir un parcours, etc.), modifier ou annuler une mission exis- 
tante. 

Suivre une mission (Chauffeur) : 



O Intention : informer en temps reel de I'etat d'avancement de chaque mission en 
cours ; 

O Actions : transmettre chaque arret/depart d'etape, signaler les evenements de mis- 
sion (acquittement client, panne, retard, absence client, etc.). 



Maintenant que nous avons identifie les cas d'utilisation et leurs acteurs, nous 
allons pouvoir les representer graphiquement sur un diagramme de cas d'utili- 
sation, dont la notation graphique de base est la suivante : 




Consulter les en-cours 



Figure 4-2. : Exemple de diagramme de cas d'utilisation de SIVEx 
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DIASRAMME DE CAS D'UTILISATION : DETAILLEZ LES ROLES (PRINCIPAL 
OU SECONDAIRE) ETLE SENS DES ASSOCIATIONS ! 

Pour ameliorer le contenu informatif des diagrammes de cas d' utilisation, 
nous recommandons d' adopter les conventions suivantes : 

>■ par defaut, le role d'un acteur est « principal » ; si ce n'est pas le cas, indi- 
quez explicitement que le role est « secondaire » sur l'association, du 
cote de 1' acteur ; 

*- si un acteur a pour role unique de consommer des informations du sys- 
teme, sans modifier l'etat de celui-ci au niveau metier, representez cette 
particularite en ajoutant une fleche vers 1' acteur sur son association 
avec le cas d' utilisation ; 

*- si un acteur a pour role unique de fournir des informations au systeme 
sans en recevoir, representez cette particularite en ajoutant sur l'asso- 
ciation une fleche vers le cas d' utilisation. 

Dans l'exemple precedent, nous avons trois cas de figure differents : 

Gerer les infos clients, qui n'a qu'un seul acteur principal : le 
receptionniste. 

Traiter une commande, qui a deux acteurs : le receptionniste qui est princi- 
pal, et le client qui est secondaire. 

Consult er les en-cours, qui a egalement deux acteurs. Tous deux peuvent 
acceder a la meme fonctionnalite metier. Dans ce cas, 1' acteur principal est 
celui qui tire reellement benefice des resultats du cas d'utilisation. II s'agit 
en fait du client qui passe soit directement par Internet, soit par l'interme- 
diaire du receptionniste pour obtenir F information. 

UML ne comporte pas de notation standard pour distinguer graphiquement 
ces trois cas. Mais, avec les conventions que nous avons repertoriees plus 
haut, le diagramme devient : 




Gerer les infos clients 



Acteur 
recepteur 
uniquement 





Receptionniste 



Client 



Consulter les en-cours 



Figure 4-3 :Ajouts graphiques surle diagramme de cas d'utilisation de SIVEx 
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NE REINVENTEZ PAS LA DECOMPOSITION FONCTIONNELLE ! 

Paradoxalement, malgre l'apparente simplicite du concept de cas d' utilisa- 
tion, et son acceptation immediate dans la plupart des methodes objet, il 
existe des risques importants de mauvais emploi des cas d'utilisation ! 

Ces risques sont principalement lies a : 

leur nature fonctionnelle, et non objet, 

la difficulte de savoir a quel niveau de detail s'arreter. 

Un nombre trop important de cas d'utilisation est en general le symptome 
d'une decomposition fonctionnelle descendante hierarchique. Nous avons vu 
plusieurs projets s'engluer ainsi dans des tentatives de structuration des cas 
d'utilisation en « sous-cas d'utilisation » avec plusieurs niveaux de decom- 
position, pour tenter d'arriver a des sortes de transactions elementaires. 

La decomposition fonctionnelle, tres en vogue dans les annees 80, a montre 
ses limites dans la pratique, en particulier sur les gros projets. II ne s'agit 
done pas de reintroduire, avec la decomposition des cas d'utilisation, les pro- 
blemes connus que l'approche orientee objet permet justement d'eviter ! 

Fondamentalement, un cas d'utilisation sera realise par une collaboration 
d'objets du systeme, mais cette correspondance n'est absolument pas bijec- 
tive. En effet, un objet est souvent implique dans la realisation de plusieurs cas 
d'utilisation. Ainsi, sur un gros projet, si Ton se sert uniquement des cas 
d'utilisation pour decouper le travail entre les equipes de developpement, on 
aboutit inevitablement a ce que ces equipes construisent en parallele les 
memes classes, en introduisant des incoherences. Un regroupement de classes 
suivant leur implication par cas d'utilisation a done peu de chance de perdurer 
dans l'organisation des classes d'analyse. Ces dernieres s'organiseront dans le 
modele structurel d'analyse qui vise notamment la modularite des concepts 
manipules dans le systeme. C'est cette capacite a organiser, partager, isoler et 
reutiliser des concepts qui manquait cruellement a l'approche par decomposi- 
tion fonctionnelle. 

N'oubliez pas cependant que les cas d'utilisation ne constituent pas une fin en 
soi. Leur objectif est de : 

dialoguer avec le client, 

analyser les besoins metier, 

disposer d'un support d'analyse de la valeur, 

aider a demarrer 1' analyse orientee objet en identifiant les classes candi- 
dates. 




Ne pas faire 
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LIMITEZ A 20 LE NOMBRE DE VOS CAS ^UTILISATION ! 

Le niveau de granularite des cas d' utilisation etant comme on l'a vu ires 
variable, cette limite arbitraire oblige a ne pas se poser trop de questions phi- 
losophiques et a rester synthetique. Dans les paragraphes suivants, nous 
expliquons qu'un cas d'utilisation decrit en realite un ensemble de scenarios. 
II est ainsi courant d' avoir une quinzaine de cas d'utilisation, comprenant 
chacun une dizaine de scenarios. Vous pouvez considerer ces ordres de gran- 
deur comme une limite pratique qui vous aidera a mieux situer la frontiere 
entre cas d'utilisation et scenario. 

Nous conseillons done d'identifier un nombre restreint de « grands » cas 
d'utilisation, alors que certains auteurs preconisent au contraire de nombreux 
« petits » cas d'utilisation, mais avec les risques identifies au paragraphe 
precedent. 

Decrire les cas d'utilisation 

Un cas d'utilisation represente un ensemble de sequences d'interactions entre 
le systeme et ses acteurs. Pour decrire la dynamique du cas d'utilisation, le 
plus naturel consiste a recenser toutes les interactions de facon textuelle. Le 
cas d'utilisation doit par ailleurs avoir un debut et une fin clairement identi- 
fies. II doit preciser quand ont lieu les interactions entre acteurs et systeme, et 
quels sont les messages echanges. II faut egalement preciser les variantes 
possibles, telles que les differents cas nominaux, les cas alternatifs, les cas 
d'erreurs, tout en essayant d'ordonner sequentiellement les descriptions, afin 
d'ameliorer leur lisibilite. Chaque unite de description de sequences d' actions 
est appelee enchatnement. Un scenario represente une succession particuliere 
d'enchamements, qui s'execute du debut a la fin du cas d'utilisation. 




Figure 4-4 : Representation des variantes d'un cas d'utilisation 

Les scenarios sont aux cas d'utilisation ce que les objets sont aux classes : on 
peut considerer qu'un scenario est une instance particuliere d'un cas d'utilisa- 



© 

Conseil 



70 



UML en action 



tion. L'acteur principal d'un cas d'utilisation dispose done de Fensemble des 
enchainements pour realiser une certaine tache metier. Les exceptions decri- 
vent les interruptions possibles d'execution empechant l'acteur d'obtenir sa 
plus -value metier. 



CAS D'UTILISATION : UTILISEZ LE STYLE DE DESCRIPTION ADAPTE ! 



N'oubliez pas qu'un cas d'utilisation a pour fonction de decrire une utilisa- 
tion du systeme par un acteur particulier. La facon dont vous allez proceder a 
cette description depend de la raison qui vous conduit a l'effectuer. Vous la 
presenterez d'une certaine maniere a votre client, parce que vous esperez la 
lui faire valider. Vous l'exposerez d'une autre maniere a votre equipe d'ana- 
lystes et de concepteurs, parce que vous essayez de leur donner suffisam- 
ment d' informations pour qu'ils puissent passer aux phases suivantes. 



CAS D'UTILISATION : NE MELANGEZ PAS L'lHM ET LE FONCTIONNEL ! 

Une erreur frequente concernant les cas d'utilisation consiste a les rendre 
dependants d'un choix premature d' interface homme-machine. II faudra 
entierement les redocumenter a chaque evolution d' interface, alors qu'il 
s'agit en fait toujours du meme cas d'utilisation fonctionnel. Encore une 
fois, F usage des cas d'utilisation, dans le cadre de la branche fonctionnelle 
du processus 2TUP vise exclusivement la description du metier des acteurs. 

Pour illustrer notre recommandation en faveur du developpement des cas d'utili- 
sation metier, nous preferons exprimer un enchainement de la facon suivante : 
« Lors d'une premiere prise de commande, le receptionniste doit enregis- 
trer les caracteristiques du nouveau client dans le systeme » ; 

a 1' inverse de : 

« Le receptionniste doit saisir le nom du client sur 8 caracteres maximum, 
appuyer sur ENTER, puis saisir le prenom sur 8 caracteres maximum et 
appuyer sur ENTER » ; 

ou bien de : 

« Le receptionniste enregistre au moyen du dispositif de reconnaissance 
vocale le nom du client, son prenom, son adresse, son code postal ». 

La regie consiste a ne pas alourdir la description des sequences logiques d' inte- 
ractions entre les acteurs et le systeme de considerations techniques d'lHM, et de 
maniere plus generate de considerations qui concernent la mise en application du 
metier sous forme informatique. Cela n'empeche pas d'annexer a la description 
du cas d'utilisation une proposition d'lHM si le client le souhaite, ou mieux, un 
descriptif des besoins d'lHM. Cette derniere proposition permet de ne pas figer 
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trap rapidement FIHM, ce qui risquerait de multiplier les styles et de nuire a 
Fergonomie d' ensemble. On developpera en revanche une consolidation de 
F application, en fonction des besoins d'lHM, en procedant a une analyse de la 
valeur sur les besoins reels du metier et en faisant intervenir un specialiste des 
IHM pour developper une maquette globale des ecrans. 



CAS D'UTILISATION : COMMENT STRUCTURER LES FICHES DE CAS 
D'UTILISATION ? 

La fiche de description textuelle d'un cas d'utilisation n'est pas normalised 
par UML. Nous preconisons pour notre part la structuration suivante : 

>- Sommaire d'identiflcation (obligatoire), 

inclut titre, but, resume, dates, version, responsable, acteurs... 
>- Description des enchainements (obligatoire), 

decrit le scenario nominal, les enchainements alternatifs, les 
enchainements d'exception, mais aussi les preconditions, et les postcon- 
ditions. 

>■ Besoins d'lHM (optionnel), 

ajoute eventuellement les contraintes d'interface homme-machine : ce 
qu'il est necessaire de montrer, en conjonction avec les operations que 
l'utilisateur peut declencher. . . 
>- Exigences non fonctionnelles (optionnel). 

ajoute eventuellement les informations suivantes : frequence, volumetrie, 
disponibilite, fiabilite, integrite, confidentialite, performances, concur- 
rence, etc. Ces informations peuvent servir a mieux evaluer les contraintes 
techniques, et pourront ameliorer, par consolidation, la capture des besoins 
operee en parallele par rarchitecte technique (voir chapitre 5). 



ETUDE DE CAS : CAS D" UTILISATION « PLANIFIER UNE MISSION » 

Sommaire d'identification : 

Titre : Planifier une mission 

But : planifier une mission d'une agence a partir de la connaissance du plan de transport, 
des ressources disponibles et des commandes a assurer quotidiennement. 

Resume : creation d'une nouvelle mission d'enlevement, de livraison ou de traction a partir 
des commandes confirmees. Modification ou annulation de mission. 

Acteurs : Repartiteur (principal), Chauffeur (secondaire). 

Date de creation : 02/02/06 Date de mise a jour : 27/01/07 

Version : 2.1 Responsable : Pascal Rogues 
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Description des enchainements : 



Preconditions : 

1 . Le repartiteur est authentifie. 

2. II existe au moins une commande confirmee a planifier. 

3. Au moins un chauffeur et un vehicule sont disponibles. 

4. Les parcours predefinis sont disponibles (plan de transport). 
Scenario nominal : 

Ce cas d'utilisation commence lorsque le repartiteur demande au systeme de creer une nou- 
velie mission. 

Enchafnement (a) Creer une mission en construction 

Le repartiteur fournit un nom d'identification et etablit obligatoirement la nature (enlevement, 
livraison ou traction) de la mission qu'il veut creer. 

S'il s'agit d'une mission de traction, le repartiteur doit indiquer une agence principale de des- 
tination. 

Enchafnement (b) Affecter les commandes 

Le repartiteur affecte les commandes a une mission. Le systeme evalue au fur et a mesure 
des affectations le tonnage et la duree estimes de la mission. 

Enchafnement (c) Affecter les ressources 

Le repartiteur affecte un vehicule et un chauffeur a la mission, en fonction du tonnage evalue. 

Si la mission depasse la capacite du vehicule alors il faut executer 
[Exception 1 : depassementTonnage] 

Si le chauffeur n'a pas les qualifications requises pour conduire le vehicule alors il faut executer 
[Exception 2 : chauffeurNonQualifie]. 

Si le tonnage de reserve de I'agence est entame alors il faut executer 
[Exception 3 : tonnageReserveEntame]. 

Enchafnement (d) Definir le trajet 

Le repartiteur propose I'ordre des etapes a suivre. Pour une traction, il suffit de choisir un parcours 
parmi ceux prevus dans le plan de transport. Pour une livraison ou un enlevement, le repartiteur 
peut avoir a choisir plusieurs parcours pour rejoindre tous les sites etapes de la mission. 

Enchafnement (e) Valider une mission en construction 

Le repartiteur valide une mission en construction : il doit alors preciser I'heure de depart pre- 
vue. Le systeme edite alors les bordereaux de mission. Ces bordereaux contiennent une fiche 
de description et de reception par commande ainsi qu'une feuille de route decrivant les eta- 
pes et les horaires estimes. 
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Enchainements alternatifs : 

Enchafnement (f) Modifier une mission en construction 

Le repartiteur desaffecte une commande, ou affecte a nouveau le vehicule et le chauffeur 
d'une mission en construction. Le repartiteur modifie egalement a son gre I'ordre des etapes 
propose pour la mission. 

Enchafnement (g) Modifier une mission validee 

Le repartiteur peut encore modifier une mission au minimum 1 heure avant son depart. Toute 
modification d'une mission validee entrainant son invalidation, il doit done ensuite la valider a 
nouveau en precisant une heure de depart. 

Enchafnement (h) Annuler une mission 

Le repartiteur annule une mission non encore validee ou une mission validee au minimum 1 
heure avant son depart. 

Ce cas d'utilisation se termine lorsque le repartiteur a : 

• amene la mission jusqu'a son depart, 

• ou bien annule la mission. 



Exceptions : 

[Exception 1 : depassementTonnage] ou [Exception 2 : chauffeurNonQualifie] : la mis- 
sion est marquee en anomalie tant que le repartiteur n'a pas corrige I'erreur. II ne peut plus 
valider une telle mission. 

[Exception 3 : tonnageReserveEntame] : un message d'erreur reste affiche sur I'ecran du 
repartiteur, tant que le tonnage de reserve n'est plus assure. 

Postconditions : 

1 . Le vehicule affecte a une mission validee possede la capacite de tonnage necessaire. 

2. Le chauffeur affecte a une mission validee possede la qualification necessaire. 

3. Les commandes d'une mission validee sont considerees comme programmees du point 
de vue du receptionniste. 

Besoins d'lHM : 



O Pour lister les commandes concernant I'agence 

Afin d'etablir la planification de ses missions, le repartiteur doit pouvoir repertorier les 
commandes que son agence doit assurer. 

II doit pouvoir filtrer ou ordonner cette liste suivant : 

• le type de commande (enlevement, traction ou livraison), 

• lepoids, 

• le site desservi, 

• I'affectation a une mission ou non, 

• la tarification urgent/non urgent. 
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Chaque ligne de la liste represente une commande et regroupe I'ensemble des informations de 
filtre. 

Une couleur differente doit permettre de distinguer les commandes affectees de celles qui ne le 
sont pas. 

Le repartiteur peut affecter les commandes aux missions depuis cette liste. 

O Pour lister les vehicules et les chauffeurs disponibles a I'agence 

Le repartiteur doit pouvoir repertorier les vehicules et les chauffeurs dont il dispose dans 
I'agence. II peut filtrer ou ordonner ces deux listes par tonnage pour les vehicules, par qualifica- 
tion pour les chauffeurs. 

Le repartiteur peut affecter les ressources aux missions depuis ces deux listes. 

O Pour lister les missions definies dans I'agence 

Le repartiteur doit pouvoir repertorier les missions deja definies pour I'agence. II peut filtrer ou 
ordonner cette liste suivant : 

• I'etat de validation, 

• la nature (enlevement, livraison, traction), 

• les sites desservis, 

• le tonnage deja affecte. 

Une couleur differente doit permettre de distinguer les missions validees de celles qui ne le sont pas. 

O Pour consulter ou modifier une mission 

Le repartiteur dispose d'une fiche par mission. Plusieurs fiches peuvent etre ouvertes simultane- 
ment. Cette fiche recapitule : 

• la nature de la mission, 

• le tonnage deja affecte, 

• I'heure de depart si la mission est validee, 

• les ressources affectees a la mission, 

• la liste ordonnee des etapes avec les commandes concernees et I'horaire de passage 
estime. 

Depuis cette fiche, le repartiteur peut modifier les ressources et les commandes affectees, 
permuter I'ordre des etapes, saisir les estimations de parcours manquantes, et valider la mission. 

Exigences non fonctionnelles : 



Exigence 


Descriptif 


Temps de 
reponse 


L'interface du repartiteur doit reagir en I'espace de deux secondes au maxi- 
mum. 


Concurrence 


Les validations de mission doivent etre notifiees par un message divertisse- 
ment aux autres lecteurs potentiels de la mission. 


Frequence 


Non applicable. 


Volumetrie 


Une mission represente en moyenne 0,5 Ko de donnees. Le nombre moyen estime 
de missions par mois est de 46 000, et leur duree de retention doit etre de 6 mois. 


Disponibilite 


Le systeme est accessible aux repartiteurs 6 jours sur 7, aux heures d'ouver- 
ture des agences. 
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Integrite 


Non applicable dans la mesure ou les missions d'une agence ne sont accessi- 
bles qu'au seul repartiteur en modification. 


Conf identia- 
lite 


Les repartiteurs sont identifies par le systeme en fonction de leur nom, de leur 
mot de passe et du role qu'ils detiennent dans I'agence. 


Integration 
des applica- 
tions 


Lors de la validation d'une mission, toutes les commandes affectees passent 
automatiquement a I'etat « shipped » dans le CRM SIEBEL. Le numero de 
mission est transmis comme reference du shipping. 
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COMPLETEZ LES DESCRIPTIONS TEXTUELLES AVEC DES DIAGRAMMES 
DYNAMIQUES SIMPLES ! 

Pour documenter les cas d'utilisation, la description textuelle est indispensable, 
car elle seule permet de communiquer facilement et precisement avec les utili- 
sateurs. Elle est egalement Foccasion de s'entendre sur la terminologie 
employee, ainsi que d'identifier le contexte d' execution de l'un ou de l'autre 
des enchainements. En revanche, le texte presente des desavantages puisqu'il 
est difficile de montrer comment les enchainements se succedent ; en outre la 
maintenance des evolutions s'avere souvent perilleuse. 

II est done recommande de completer la description textuelle par un ou plu- 
sieurs diagrammes dynamiques, qui apporteront un niveau superieur de for- 
malisation. A vous de decider en fonction de votre contexte si vous montrez 
ces diagrammes au futur utilisateur, ou si vous les utilisez uniquement 
comme support d' analyse pour lui poser des questions supplementaires, et 
ainsi mieux valider votre texte. 



Texte 
















Diagramme 
d'activite 




Diagramme d'etats 



Bat J— > 


Hat] 


t 






Hat J 



Diagramme de 
sequence 



Figure 4-5 : Types de diagrammes dynamiques utilisables pour documenter les cas 

d'utilisation 
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Les criteres de choix entre les differents types de diagrammes dynamiques 
utilisables sont enumeres de facon plus detaillee ci-apres : 

Pour documenter les cas d'utilisation : 

Le diagramme d'activite est celui que nous recommandons particulie- 
rement, car il permet de consolider les enchainements de la fiche textuelle, 
comme nous Favions represente informellement sur la figure 4-4 . Ce dia- 
gramme est egalement tres utile en cas d' actions paralleles. De plus, les 
utilisateurs le comprennent aisement, car il ressemble a un organigramme 
traditionnel. II permet enfin d'identifier d'un seul coup d'ceil la famille des 
scenarios d'un cas d'utilisation qui decrivent toutes les reactions du sys- 
teme. II suffit en effet de dessiner les differents chemins du diagramme 
d'activite qui passent par toutes les transitions entre actions. 

Le diagramme d'etats se prete mieux a la modelisation d'un deroulement 
evenementiel. II est neanmoins plus complexe a comprendre pour les utili- 
sateurs du monde de la gestion. 

Pour illustrer des scenarios particuliers : 

Le diagramme de sequence est une bonne illustration. II est facilement 
compris par les utilisateurs. De plus, il servira de base aux diagrammes de 
sequence dont nous parlerons au chapitre 8, et qui mettront en jeu des 
objets du systeme. 

Le diagramme de communication est une autre illustration possible. II est 
cependant ici moins utile que le precedent pour les utilisateurs, car il rend 
la sequence moins claire, sans apporter de veritable plus-value au dia- 
gramme de sequence. 



ETUDE DE CAS : CAS D" UTILISATION « PLANIFIER UNE MISSION » 

Au cas d'utilisation decrit precedemment, nous allons ajouter un diagramme d'activite qui va pre- 
ciser I'enchatnement des actions a entreprendre, avec les branchements conditionnels et les 
boucles possibles. Le cas d'utilisation est exprime du point de vue de I'utilisateur ; par conse- 
quent les actions correspondent a celles effectuees par I'utilisateur avec le systeme. II taut done 
interpreter I'action « estimer parcours » non comme une action interne du systeme, mais comme 
une demande directement declenchee par I'utilisateur et suivie de son attente de la reponse. 



Chapitre 4 • Capture des besoins fonctionnels 



77 



crier mission 



modifier mission 



5 



[ parcours incomplet ] 



[ > 1 heure 
avanl depart ] 



estjmer parcours 



( reserve entamee 
pas d'anomalie J 



afficher reserve entamee 



annulation ] 



valider mission <r 




imprimer bordereau 



* [ depart mission ] 

Figure 4-6 : Diagramme d'activite du cas « Planifier une mission » 

Nous pouvons egalement ajouter un diagramme de sequence montrant le scenario nominal de 
creation d'une nouvelle mission. Notez le positionnement de I'acteur principal a gauche du sys- 
teme (vu comme une boite noire) et de I'acteur secondaire a droite. 

Notez egalement la possibility offerte par UML 2 de modeliser des boucles dans le diagramme 
de sequence grace a I'operateur « loop ». 



:Repartiteur 



:SIVEx 



:Chauffeur 



loop 



creation mission(nom, nature) 



-^1 



[pour chaque commande choisie] 
affectation d'une commande a la mission 



k- 



tonnage et duree estimes 



liste ressources disponibles 



affectation vehicule 



affectation chauffeur 



^1 

^1 



validation mission (heure depart) 



bordereaux de mission 



Figure 4-7 : Diagramme de sequence du scenario nominal du cas « Planifier une mission » 
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Organiser les cas d'utilisation 

On peut organiser les cas d'utilisation de deux facons differentes et comple- 
mentaires : 

en ajoutant des relations d'inclusion, d'extension, et de generalisation 
entre les cas d'utilisation ; 

en les regroupant en packages, afin de definir des blocs fonctionnels de 
plus haut niveau. 



LES RELATIONS POSSIBLES ENTRE CAS D'UTILISATION 

UML definit trois types de relations standardises entre cas d'utilisation, 
detaillees ci-apres : 

une relation d'inclusion, formalisee par un mot-cle «include», 
une relation d'extension, formalisee par un mot-cle «extend», 
une relation de generalisation/specialisation. 



LA RELATION «INCLUDE» ENTRE CAS ^UTILISATION 

Relation d'inclusion : le cas de base en incorpore explicitement un autre, a 
un endroit specifie dans ses enchalnements. Le cas d'utilisation inclus n'est 
jamais execute seul, mais seulement en tant que partie d'un cas de base plus 
vaste. 




«incluiic» 
Inclus 
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Remarquez que dans une relation « include », le cas d'utilisation de base 
utilise systematiquement les enchainements provenant du cas inclus. On 
utilise frequemment cette relation pour eviter de decrire plusieurs fois le 
meme enchainement, en factorisant le comportement commun dans un cas 
d'utilisation a part. 
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© 



Ne pas faire 



INCLUSION : PAS DE DECOMPOSITION FONCTIONNELLE ! 

Une habitude malheureusement assez repandue consiste a utiliser la relation 
d' inclusion pour decomposer un cas d' utilisation en « sous-cas d' utilisa- 
tion », retombant dans le travers de la decomposition fonctionnelle evoque 
precedemment. 



ETUDE DE CAS : INCLUSION DU CAS D" UTILISATION 
« S'AUTHENTIFIER » 

Si Ton examine en detail les descriptions textuelles des cas d'utilisation du systeme SIVEx, on 
s'apergoit rapidement que dans toutes les preconditions, on a specifies que I'acteur principal du 
cas d'utilisation doit s'etre authentifie. 

En fait, le processus d'authentification implique un flot d'evenements entre I'acteur et le systeme : 
saisie d'un login, puis d'un mot de passe, avec les differents cas d'erreur possibles. Cet enchai- 
nement fait partie de la capture des besoins, puisqu'il est visible de I'utilisateur final ; neanmoins 
il n'est pas de meme niveau que les cas d'utilisation que nous avons deja identifies. II correspond 
tout a fait a la notion de cas d'utilisation inclus, ne s'executant jamais seul, mais seulement 
lorsqu'il est appele par un cas d'utilisation plus large. 




Figure 4-8 : Relation «include» entre cas d'utilisation 




LA RELATION « EXTEND » ENTRE CAS D'UTILISATION 



Relation d' extension : le cas de base en incorpore implicitement un autre, a 
un endroit specifie indirectement dans celui qui etend. Le cas de base peut 
fonctionner tout seul, mais il peut egalement etre complete par un autre, sous 
certaines conditions, et uniquement a certains points particuliers de son flot 
d'evenements appeles points d'extension. 
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(Point 
d' extension) 



L 



base 

«extend» 
■ 

extension 



Notez que dans une relation « extend », le cas d' utilisation de base recourt 
optionnellement aux enchainements provenant du cas d'extension. On utilise 
principalement cette relation pour separer le comportement optionnel (les 
variantes) du comportement obligatoire. 



ETUDE DE CAS : EXTENSION DU CAS « TRAITER UNE COMMANDS » 

Dans le cas d'utilisation « Traiter une commande », un des enchainements principaux consiste a 
creer une nouvelle commande. Or, si le client est inconnu du systeme SIVEx, le receptionniste va 
devoir interrompre son processus de creation de commande pour tenter auparavant de creer un 
nouveau client. Si ce processus se deroule sans encombre, il pourra alors continuer sa creation 
de commande. Le processus de creation de client, pour sa part, tait partie integrante du cas 
d'utilisation « Gerer les infos clients ». II est done interessant de preciser cette relation d'exten- 
sion entre les deux cas d'utilisation. 

Cas d'utilisation Relation d'extension 




Point d'extension 



Figure 4-9. : Relation «extend» entre cas d'utilisation 



LA RELATION DE GENERALISATION ENTRE CAS D'UTILISATION 

Les cas d'utilisation peuvent etre hierarchises par generalisation/ specialisa- 
tion. Les cas d'utilisation descendants heritent de la semantique de leur 
parent. lis peuvent comprendre des interactions specifiques supplementaires, 
ou modifier les interactions heritees. 
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ETUDE DE CAS : SPECIALISATION DU CAS « PLANIFIER 
UNE MISSION » 

Si nous reprenons la description textuelle du cas d'utilisation « Planifier une mission », nous pou- 
vons sans conteste identifier de legeres variations dans les enchamements, suivant le type de la 
mission traitee (enlevement, traction, livraison). 

Par exemple, dans I'enchainement (a), un comportement supplemental pour les missions de 
traction est precise : « S'il s'agit d'une mission de traction, le repartiteur doit indiquer une 
agence principale de destination ». De meme, I'enchainement (e) conduit a I'edition de borde- 
reaux de mission differents en fonction de la nature de la mission. 

Nous pouvons done eventuellement identifier des cas d'utilisation specialises suivant le type de 
mission, avec, en I'occurrence, un cas d'utilisation general abstrait (il ne s'instancie pas directe- 
ment, mais uniquement par le biais de I'un de ses cas specialises). 




une traction Planifier une 
livraison 

Figure 4-10 : Relation de generalisation entre cas d'utilisation 



VOUS POUVEZ AUSSI GENERALISE!* LES ACTEURS ! 

Si un ensemble d'acteurs communiquent de la meme facon avec certains cas 
d'utilisations, on peut creer un acteur generalise (souvent abstrait), qui per- 
mettra de factoriser ce role commun. Les acteurs specialises heritent alors 
des associations de 1' acteur ancetre. 



ETUDE DE CAS : ACTEUR GENERALISE « UTILISATEUR » 

Revenons sur le processus d'authentification identifie plus haut. II est inclus dans tous les autres, 
et implique le meme type de flot d'evenements entre chaque acteur et le systeme. Pour le repre- 
sentor sur un diagramme de cas d'utilisation, le plus efficace consiste a creer un acteur abstrait 
« Utilisateur », associe au cas d'utilisation « S'authentifier », qui generalise tous les acteurs de 
SIVEx, sauf bien entendu le vehicule. 
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Acteur 
generalise 
abstrait 



. Utilisateur 



S'authentifier 



A 



Client Receptionniste Complable Repartiteur Chauffeur Operateur de ResponsaWe Administtateur 

quai logistique systeme 

Figure 4-11 : Acteur generalise « Utilisateur » 



Pour definir la strategic de regroupement des cas d'utilisation pour un projet, 
il convient de recourir a la liste suivante de criteres : 

par domaine d'expertise metier : le plus intuitif et souvent le plus efficace. 

II facilite la specialisation des analystes et permet d' organiser la disponibi- 

lite des differents experts ; 

par acteur : simple a mettre en ceuvre uniquement si chaque cas d'utilisation est 
relie a un et un seul acteur, sinon il s'apparente souvent au critere precedent ; 
par lot de livraison : dans le cadre d'un developpement iteratif et incre- 
mental, il est interessant de regrouper dans un meme package les cas d'uti- 
lisation qui seront livres ensemble au client. Du coup, la structuration peut 
etre tres differente de celle obtenue en appliquant le premier critere. 
Le mecanisme generique de regroupement d'elements en UML s'appelle le 
package. Nous allons y recourir dans cette activite, afin de structurer notre 
ensemble de cas d'utilisation. 



QU'EST-CE QU'UN PACKAGE ? 

Un package UML represente un espace de nommage qui peut contenir : 
des elements d'un modele, 

des diagrammes qui representent les elements du modele, 
d'autres packages. 

Les elements contenus dans un package : 

doivent representer un ensemble fortement coherent, 

sont generalement de meme nature et de meme niveau semantique. 

Nous allons appliquer ces principes aux cas d'utilisation definis pour SIVEx. 



G 

Definition 
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ETUDE DE CAS : STRUCTURATION DES CAS D" UTILISATION 

Le critere de regroupement retenu pour le systeme SIVEx est le premier cite, soit le domaine 
d'expertise metier. II correspond egalement a un decoupage par ensemble d'acteurs fortement 
relies. Si nous reprenons le tableau preliminaire, en affectant chaque cas d'utilisation a un pac- 
kage, nous obtenons ce qui suit : 



Cas d'utilisation 


Acteurs 


Package 


Traiter une commande 


Receptionniste 


Gestion clientele 




Client 




Gerer les infos clients 


Receptionniste 




Consulter les en-cours 


Client 






Receptionniste 




Planifier une mission 


Repartiteur 


Gestion missions 




Chauffeur 




Suivre une mission 


Chauffeur 






Repartiteur 






Vehicule 




Gerer la facturation 


Comptable 


Comptabilite 


Suivre les reglements 


Comptable 




Realiser I'inventaire 


Operateur de quai 


Traitement colis 


Manipuler les colis 


Operateur de quai 




Definir le plan de transport 


Responsable logistique 


Logistique 


Gerer les ressources 


Responsable logistique 




Gerer les profils 


Administrateur 


Services support 



Tableau 4-4 : Liste des cas d'utilisation et de leurs acteurs par package 

Chaque package de cas d'utilisation occasionne la creation d'un diagramme. Voici les deux plus 
interessants : 




Consulter les en-cours 



Figure 4-12 : Diagramme de cas d'utilisation du package « Gestion clientele » 
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Planifer une livraison 

Figure 4-13: Diagramme de cas d 'utilisation du package « Gestion missions » 



Decrire les cas d'utilisation en identifiant les flux entre applications 

La description des cas d'utilisation doit etre l'occasion d'identifier les flux de 
type EAI qui servent a la synchronisation entre les differentes applications 
participant au systeme. Une premiere technique consiste a ajouter une 
contrainte non fonctionnelle nommee « integration des applications » pour 
decrire les echanges entre applications lors du deroulement du cas d'utilisa- 
tion ; vous avez pu en avoir un apercu precedemment, lors de la description du 
cas d'utilisation « Planifier une mission ». 

Cependant, 1' identification des flux de synchronisation est souvent le sujet 
d'une analyse attentionnee dans la mesure ou Ton aborde ici des aspects 
d'urbanisme qui, au cceur du systeme d' information, touchent un domaine que 
doivent absolument valider les experts metier. En consequence, la description 
des processus metier implique de montrer la repartition des activites entre les 
applications. En fonction du type de projet, cette description peut etre utilisee 
soit au moment de la modelisation metier, soit comme nous allons l'illustrer, 
sur le diagramme d'activite d'un cas d'utilisation. 



Chapitre 4 • Capture des besoins fonctionnels 



85 



ETUDE DE CAS : CAS D'UTILISATION « fiERER LES INFOS CLIENTS » 
- IDENTIFICATION DES FLUX EAI 

Une pratique d'urbanisme courante consiste a utiliser une application comme referentiel des objets 
metier. Typiquement dans notre exemple, I'ERP SAP R/3 sert de referentiel des clients de I'entreprise, 
tandis que le CRM SIEBEL contient la reference des commandes. Bien entendu, ces deux applica- 
tions ont besoin d'echanger leurs donnees car SIEBEL doit contenir les objets clients suivant son pro- 
pre format pour fonctionner correctement et inversement pour les objets commandes. 

Conformement aux propositions du profil « UML for EAI » de I'OMG, le diagramme d'activite ci- 
dessous peut etre utilise pour identifier puis etudier les echanges necessaires. Ce diagramme 
decrit une partie du cas d'utilisation « Gerer les infos clients ». 



«Subsyslem» 
Application du Receptionnlste 
(CRM SIEBEL) 




4 



(creer client en ^ 
phase devente^ --—^ 



C 



Definition 
Client 



pivot} 



modifier les coordonnees du 
client en phase de vente 



1 



{transformation 
pivot} 



SAP ♦ creation) 



< completer profil \ 
financier J 



Definition 
Client 



venfier profil N 
^nTfoTma^n V financier J 



SAP + verification 
+ modifications) 



Figure 4-14 : Diagramme d'activite « Creer ou modifier un client en phase de vente » 

Remarquez que les echanges s'expriment sous la forme de flux d'objets et que les contraintes 
servent a identifier les actions a realiser dans le processus d'integration. Nous voyons ainsi qu'il 
faut transformer la definition du client SIEBEL dans un format intermediaire, dit pivot, puis trans- 
former a nouveau ce format pour faciliter sa creation dans SAP. 



Identifier les classes candidates 



Comme nous l'avons deja mentionne, la definition des cas d'utilisation ne doit 
pas etre une fin en soi ! 



86 



UML en action 



La technique mise au point par Ivar Jacobson [Jacobson 92] comporte deux 
objectifs principaux : 

dialoguer avec le client sur son expression preliminaire de besoins grace a 
une description fonctionnelle qu'il comprend facilement, 

preparer la modelisation orientee objet en aidant a trouver les classes prin- 
cipales du futur modele statique d' analyse. 

Les paragraphes precedents de ce chapitre traitent du premier objectif. Nous 
allons maintenant aborder le second. Le travail que Fanalyste va desormais 
effectuer complete d'ailleurs le precedent, car en mettant a jour les principales 
abstractions du systeme sous forme d'objets et de classes, Fanalyste continue 
son dialogue avec le client. II essaie ainsi d'obtenir rapidement un consensus 
sur les definitions des concepts cles. 

Les premieres classes candidates identifiees dans cette phase doivent etre des 
concepts connus des utilisateurs du systeme, ce qu'on appelle couramment (et 
abusivement, puisque ce sont des classes) des objets metier. Exemples pour 
l'etude de cas : Mission, Commande, Client, Agence, Colis, etc. 

Lanalyste ajoutera dans un second temps des concepts « applicatifs », lies a 
l'informatisation. Exemples pour l'etude de cas : Etiquette a code-barre, 
Profil utilisateur, etc. 

Cherchez les noms communs importants dans les descriptions textuelles des 
cas d'utilisation. Verifiez les proprietes « objet » de chaque concept (identite, 
proprietes, comportement), puis definissez ses responsabilites. 



QU'EST-CE QU'UNE RESPONSABILITE ? 

Definition Une responsabilite est une sorte de contrat, ou d'obligation, pour une classe. 

Elle se place a un niveau d' abstraction plus eleve que les attributs ou les ope- 
rations. En fait, on peut dire que les attributs, les operations, et les associa- 
tions represented les proprietes elementaires qui contribueront a remplir les 
responsabilites de la classe. 



Vehicule 









Responsabilites l 

r- connatlre ses capacites 
(poids max. en charge, 
encombrement, etc.) ; 

- connaitre son agence de 
rattachement ; 

— savoir s'il est affecte a une 
mission, ou s'il est libre. 



Figure 4-15: Responsabilites de la classe Vehicule 
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En pratique, une classe doit avoir au moins une responsabilite, mais surtout un 
nombre tres limite. Si elle comporte plus de cinq responsabilites, elle doit etre 
subdivisee en plusieurs classes. 

Graphiquement, les responsabilites peuvent etre dessinees dans un comparti- 
ment separe, au dessous des compartiments des attributs et des operations. 
Dans la pratique, les outils du marche incitent plutot a ecrire des phrases 
courtes repertoriees dans une note graphique attachee a la classe. 

Dans l'exemple precedent, il est probable que la premiere responsabilite se 
traduira par des attributs, et les suivantes par des associations. 

On formalise ensuite ces concepts metier sous forme de classes et d' associa- 
tions rassemblees dans un diagramme statique pour chaque cas d'utilisation. 
Ces diagrammes preliminaries, que nous appelons « diagramme de classes 
participates », n'ont pas d'objectif d'exhaustivite. lis servent uniquement a 
demarrer la decouverte des classes du modele d' analyse pour la partie de 
1' application delimitee par un cas d'utilisation. La reunion de tous les 
diagrammes, apres elimination des classes et associations redondantes, doit 
representer le squelette du modele statique d' analyse. 



ETUDE DE CAS : DIAGRAMME DES CLASSES PARTICIPANTES DU CAS 



Agence 



Chauffeur 



est responsable de 



estaffectea 0.1 



estaffectea 0..1 



1 conlient 1..* 



Etape 



0..1 



Vehicule 



traite 



1..* 



Commande 



Figure 4-16 : Diagramme des classes participantes de « Planifier une mission ; 
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Si Ton exploite la description textuelle du cas d'utilisation donnee plus haut, on peut ajouter en 
particulier : 

• le type de mission : enlevement, livraison, ou traction. Une association doit etre ajoutee pour 
les missions de traction qui ont une agence de destination ; 

• les bordereaux pour les missions validees : une feuille de route et une fiche par commande ; 

• une mission est composee de differentes etapes. Une etape est planifiee pour chaque com- 
mande. 

II serait illusoire de penser tiger les multiplicity des associations a ce moment-la. Des questions 
vont certainement se reposer regulierement au fur et a mesure de I'avancement de I'analyse : 0 
ou 1 ?, 1 ou plus ? C'est normal I 

Remarque : nous avons volontairement limite I'utilisation des constructions du diagramme de 
classes, afin de ne pas anticiper sur les concepts qui seront abordes aux chapitres suivants. 



Chauffeur 



Agence 



Vehicule 



Traction 




Commande 



Etape 



est planifiee pour 



0.1 



Figure 4-17 : Diagramme des classes participantes complete de « Planifier une mission ; 
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ETUDE DE CAS : DIAGRAMME DES CLASSES PARTICIPANTES DU CAS 
D'UTILISATION « TRAITER UNE COMMANDE » 

D'apres la description initiale des besoins, on identifie les classes et associations suivantes : 



Agence 



O 



1..* 



est acheminee via 



enlevement 




Receptionniste 




1 


a c 


'ee 



Commande 



Client 



decrit 



1..* 



Colis 



Figure 4-18: Diagramme des classes participantes de « Traiter une commande » 



Valider et consolider 

La revision des cas d' utilisation doit absolument inclure une phase de presen- 
tation aux futurs utilisateurs et poser les questions cles ci-apres : 

Les frontieres du systeme sont-elles bien definies ? 

Les acteurs sont-ils tous pris en compte (au moins une fois) ? 

Chaque cas d'utilisation a-t-il un processus de declenchement (par un acteur) ? 

Le niveau d' abstraction des cas d'utilisation est-il homogene ? 

Toutes les fonctionnalites du systeme sont-elles traitees ? 
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IL FAUT ASSURER LA TR AC A BILITE DES CAS ^'UTILISATION AVEC 
L'EXPRESSION DES BESOINS ! 

Concretement, on realisera une matrice de tracabilite entre cas d'utilisation 
et elements de cahier des charges. Cette matrice pourra etre detaillee pour 
faire apparaitre les differents enchainements de chaque cas d'utilisation. 







Exigence 1 


Exigence 2 


Exigence 3 


Exigence 4 


Exigence 5 


Use 
case A 


scenanol 












scenano2 




X 




X 


t 


scenano3 




X 




x 


X 


Use 
case B 


scenanol 












scenario 2 




X 




X 




scenano3 




X 




X 




scenano4 












Use 
caseC 


scenanol 












scenano2 




X 




X 





Cela permettra, dans la suite de F analyse, d'etablir le suivi des classes avec le 
cahier des charges, par le biais des cas d'utilisation ; il sera meme possible de 
retrouver les operations impliquees. L'aide d'un outil est alors precieuse. La 
figure suivante montre par exemple les informations que Rational/Rose sait 
fournir. 
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figure 4-79 : Rational/Rose : « Report - Show Participants in UC » 



Cette tracabilite entre besoins de haut niveau et operations permet 
d'ameliorer notablement la capacite de maintenance et d'evolution du code, 
tout au long de la vie de 1' application. 
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SERVEZ-VOUS DES CAS D'UTILISATION POUR DEFINIR VOS ITERATIONS ! 

Dans le cadre d'un developpement iteratif et incremental, il est tres utile de 
recourir au decoupage en cas d'utilisation pour definir les iterations. A cet 
effet, il convient en premier lieu d' identifier les cas d'utilisation les plus cri- 
tiques en termes de gestion des risques. Ces cas d'utilisation devront etre 
traites prioritairement afin de lever au plus tot les risques majeurs. II sera 
egalement demande au client d'affecter une priori te fonctionnelle a chaque 
cas d'utilisation, afin de livrer d'abord les cas d'utilisation les plus deman- 
ded. Ces deux criteres pouvant etre contradictoires, la decision du decoupage 
en iterations incombe au chef de projet, qui doit le faire valider par le client. 

II faut aussi prendre en compte les eventuelles relations entre cas d'utilisa- 
tion : 

developper plutot les cas factorises («include») avant ceux qui les utilisent ; 
developper plutot les cas qui etendent («extend») apres les cas de base. 

ETUDE DE CAS : DEFINITION DES ITERATIONS 



Cas d'utilisation 


Risque 


Priorite 


Iteration 


Traiter une commande 


Moyen 


Moyenne 


5 


Gerer les infos clients 


Bas 


Moyenne 


6 


Consulter les en-cours 


Haut 


Moyenne 


3 


Gerer la facturation 


Bas 


Basse 


8 


Suivre les reglements 


Bas 


Basse 


8 


Planifier une mission 


Haut 


Haute 


2 


Suivre une mission 


Moyen 


Haute 


4 


Realiser I'inventaire 


Bas 


Moyenne 


7 


Manipuler les colis 


Bas 


Moyenne 


7 


Definir le plan de transport 


Haut 


Haute 


1 


Gerer les ressources 


Moyen 


Haute 


3 


Gerer les profils 


Bas 


Moyenne 


9 


S'authentifier 


Bas 


Moyenne 


9 



Tableau 4-5 : Definition des iterations par classement des cas d'utilisation. 

A chaque cas d'utilisation de SIVEx, nous avons affecte : 

• un risque (haut, moyen, bas), 

• une priorite fonctionnelle (haute, moyenne, basse). 



© 

Conseil 
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En fonction de ces informations et des dependances entre cas d'utilisation, nous donnons un 
exemple de decoupage du projet en iterations. Cette planification est evidemment donnee a titre 
illustratif, le processus 2TUP etant fondamentalement adaptatif et non pas predictif. 



Phases de realisation de 
I'analyse des besoins 
fonctionnels 



L' analyse des besoins fonctionnels a pour objectifs principaux de : 

completer le recueil initial des besoins effectue pendant 1' etude prelimi- 
naire : nous avons explique comment utiliser a cet effet le concept central 
de cas d'utilisation propose par UML ; 

preparer I'analyse orientee objet : pour chaque cas d'utilisation, nous 
avons vu comment identifier les classes candidates du modele statique 
d' analyse. 

La demarche mise en ceuvre dans ce chapitre est synthetisee par la figure 
suivante : 




Packages de 
specification 
fonctionnelle 



Diagrammes de 
classes participantes 



Tracabilite 



Diagrammes de 
cas d'utilisation 
raffines 



Figure 4-20. : Demarche de capture des besoins fonctionnels 



Chapitre Capture des besoins 
C techniques 



Objectifs du chapitre 

Ce chapitre traite du role d'UML lors de l'etape de capture des besoins 
techniques. Cette activite est generalement peu formalisee, soit par manque 
d'une notation et d'un processus approprie, soit parce que les architectes tech- 
niques recourent rarement a une approche formelle. Nous allons precisement 
etudier comment le concept de cas d'utilisation peut etre etendu pour repondre 
a ce besoin, et de quelle maniere le processus en Y repond particulierement 
bien a la specification technique d'un systeme client/serveur tel que SIVEx. 

Dans ce chapitre, nous allons aborder : 

la construction d'un modele d' analyse technique avec UML, 

les avantages d'une organisation en couches logicielles, 

l'emploi des cas d'utilisation pour decrire les comportements techniques 

du systeme, 

la description des cas d'utilisation techniques. 



Quand intervient la capture 
des besoins techniques ? 

La capture des besoins techniques couvre, par complementarite avec celle des 
besoins fonctionnels, toutes les contraintes qui ne traitent ni de la description du 
metier des utilisateurs, ni de la description applicative. Le modele de specifica- 
tion logicielle concerne done les contraintes techniques telles que nous avons pu 
les evoquer au chapitre 4. La specification technique est une activite de la 
branche droite du Y ; elle est primordiale pour la conception d' architecture. 
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Cette etape a lieu lorsque les architectes ont obtenu suffisamment d'informa- 
tions sur les prerequis techniques. lis doivent a priori connaitre au moins le 
materiel, a savoir les machines et reseaux, les progiciels a integrer, et les outils 
retenus pour le developpement. En cours d' elaboration, viendront s'ajouter les 
contraintes non fonctionnelles identifiers dans les cas d'utilisation de la branche 
gauche. Le niveau d' abstraction a atteindre est Fanalyse technique. Le modele 
s'y exprime suivant les deux points de vue que sont la specification logicielle et 
la structure du materiel a exploiter. Cette etape se termine lorsque le niveau de 
description des cas d'utilisation techniques a permis F identification des 
problemes a resoudre. A ce moment-la pourra debuter F etape de conception 
generique, qui consiste a construire une solution d' architecture technique. 



Branche 
fonctionnelle 



Contraintes 
techniques 



Capture des besoins 
fonctionnels 



Vnulvsr technit] uc 




Figure 5-1 : Situation de la capture des besoins techniques dans 2TUP 



Elements mis en jeu 

Diagramme de deploiement, nceuds et connexions du reseau, architecture a 
3 niveaux, 

Diagramme de composants, composants d'exploitation, architecture 3- 
tiers, 

Diagramme de cas d'utilisation, cas d'utilisation technique, description 
d'un cas d'utilisation technique, organisation en couches logicielles, archi- 
tecture en 5 couches, 

Specification logicielle detaillee. 
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Specification technique du point de vue materiel 

Les prerequis techniques ont ete exprimes dans F etude preliminaire, lors de 
l'expression des besoins operationnels et de celle des choix strategiques de 
developpement au chapitre 3. Ces choix impliquent des contraintes relatives a 
la configuration du reseau materiel. Elles sont de nature geographique, organi- 
sationnelle, et technique. Elles concernent les performances d'acces aux 
donnees, la securite du systeme, Finteroperabilite, Fintegration des applica- 
tions, la volumetrie et le mode d'utilisation du systeme. 



STYLE ^'ARCHITECTURE EN NIVEAUX 

Le style d' architecture en niveaux specifie le nombre de niveaux geographi- 
ques et organisationnels oil vont se situer les environnements d' execution du 
systeme [Orfali 94]. 

L' architecture a deux niveaux met en ceuvre un environnement de travail 
de niveau departemental et local. Un tel systeme repond generalement a la 
demande d'un metier particulier dans Fentreprise. Par exemple, le departe- 
ment des ressources humaines dispose d'un systeme informatique inde- 
pendant et localise au sein de la societe. 

L' architecture a trois niveaux met en ceuvre le systeme informatique d'une 
entreprise. Nous y trouvons les niveaux suivants : central, departemental et 
local. Une telle architecture couvre les differents metiers de Fentreprise. 
L' etude de cas SIVEx en constitue un exemple. 

La contrainte geographique conditionne egalement F architecture en 
niveaux. Le systeme de ressources humaines, reparti sur plusieurs agences 
ou departements, devient de fait un systeme a trois niveaux. La conjonc- 
tion des contraintes geographique et organisationnelle conduit done a des 
systemes complexes dotes d'une architecture multiniveaux. 

Les contraintes techniques amenent egalement a diversifier le nombre et le 

type des machines : 

soit pour des raisons de performances : e'est le cas d'un montage en clus- 
ter, 

soit pour des raisons de securite : e'est le cas de l'ajout de ponts, de rou- 
teurs ou d'un serveur dedie au Web (typiquement dans la mise en ceuvre 
d'une zone demilitarisee DMZ), 

soit pour des raisons d'interoperabilite : lorsque les logiciels sont congus 
sur des plates-formes differentes, 

soit pour des raisons de disponibilite : on privilegiera les postes de travail 
utilises 24h/24, aux terminaux utilises pour des requetes tres ponctuelles. 
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STRUCTUREZ VOS SPECIFICATIONS D'EXPLOITATION TECHNIQUE 
AUTOUR DU MODELE DE CONFIGURATION MATERIELLE 



Les specifications qui concernent l'exploitation technique d'un reseau ont 
toutes une relation directe soit avec une connexion, soit avec une machine 
particuliere du modele de configuration materielle. Du fait de leur existence, 
les machines imposent des contraintes de performances ou d'integration 
materielle. La nature des connexions permet egalement de specifier des con- 
traintes liees au besoin de communication et de bande passante. L'integra- 
tion de 1' application dans le systeme d' information existant impose de 
nouvelles contraintes liees aux machines dediees a une fonction particuliere 
du systeme informatique. 

Nous vous conseillons done d'integrer vos specifications dans le diction- 
naire du modele de configuration materielle. 



ETUDE DE CAS : LA CONFIGURATION MATERIELLE DE SIVEX 

La configuration geographique du systeme SIVEx impose le developpement d'une solution 
client/serveur a trois niveaux : un niveau central pour les informations partagees entre 
agences et consolidees pour le siege, un niveau departemental pour chaque agence et un 
niveau local pour les applications a deployer sur les postes de travail. La configuration 
materielle est schematises par un diagramme de deploiement UML a la figure 5-2. 
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Figure 5-2. : Configuration materielle du systeme SIVEx 
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Le point de vue materiel met en evidence les contraintes d'exploitation technique suivantes : 

• pour fonctionner avec les progiciels SAP R3 et SIEBEL, SIVEx doit necessairement 
integrer une technologie d'EAl ; 

• la communication WAN prise en charge par Internet est subordonnee a I'usage de 
firewalls, ce qui limite potentiellement le jeu de protocoles de communication possi- 
bles entre clients et serveurs ; 

• I'export des informations sur Internet impose d'isoler le serveur Web du reseau ethernet 
central ; 

• I'annuaire centralise de reference doit correspondre a celui qui existe sur le serveur de 
bureautique central. 



Specification d'architecture et influence sur le modele 
de deploiement 

L' expression des prerequis techniques implique egalement le choix d'un style 
d'architecture client/serveur. Ce choix conditionne la facon dont seront orga- 
nises et deployes les composants d'exploitation du systeme. 
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COMPOSANT D'EXPLOITATION 

Un composant d'exploitation est une partie du systeme logiciel qui doit etre 
connue, installee, declaree et manipulee par les exploitants du systeme. Un 
composant d'exploitation doit etre interchangeable entre differentes versions 
et peut etre arrete ou demarre separement. II assume des fonctions bien iden- 
tifiees dans le systeme, de sorte qu'en cas de dysfonctionnement, le compo- 
sant incrimine est facilement reperable. 
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STYLE D'ARCHITECTURE EN TIERS 

Le style d'architecture en tiers (tier signifie « partie » en anglais) specifie 
l'organisation des composants d'exploitation mis en ceuvre pour realiser le 
systeme. Chaque partie indique une responsabilite technique a laquelle sous- 
crivent les differents composants d'exploitation d'un systeme. 

On distingue done plusieurs types de composants en fonction de la responsabi- 
lite technique qu'ils jouent dans le systeme. Un systeme client/serveur fait refe- 
rence a au moins deux types de composants, qui sont les systemes de base de 
donnees en serveur, et les applications qui en exploitent les donnees en client. 

Le style d'architecture 2-tiers correspond a la configuration la plus simple 
d'un systeme client/serveur. Dans ce cas, il incombe aux clients de gerer 
l'interface utilisateur et les processus d'exploitation. Les serveurs ont pour 
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responsabilite de traiter le stockage des donnees. Ce type d' architecture est 
parfaitement bien adapte aux systemes departementaux, dans la mesure oil les 
concepts et les processus manipules n' existent qu'une seule fois au sein d'un 
departement de l'entreprise. 

Dans le cadre des architectures d'entreprise, certains concepts et processus 
sont communs a plusieurs domaines d'activite. Cette caracteristique implique 
une synchronisation souvent complexe des donnees entre differents departe- 
ments de l'entreprise. Le concept d'objet metier consiste a centraliser cette 
gestion afin d'en maitriser la complexite. L'objet metier est a la fois un modele 
d' analyse qui colle a la realite du probleme de l'entreprise, mais egalement un 
modele de composant d' exploitation qui s'insere dans le deploiement du 
systeme d'entreprise [Eeles 98]. L'integration des objets metier sous la forme 
de composants metier fait passer 1' architecture client/serveur du 2-tiers au 3- 
tiers, car elle implique un nouveau type de composants d' exploitation qui 
s'insere entre les clients et les serveurs de donnees. 
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COMPOSANT METIER 

Un composant metier est un composant d'exploitation dont la fonction est de 
distribuer les services d'un ou de plusieurs objets metier de l'entreprise. 
L'integration de composants metier implique le recours a un style d' architec- 
ture 3 -tiers. 

Le style d' architecture 3-tiers facilite la reutilisation au sein d'un systeme, 
puisque les composants metier correspondent a des concepts communs a 
differents metiers de l'entreprise. Dans le cas de SIVEx, les classes 
Commande et Mission sont de bons composants metiers candidats, puisqu'ils 
concourent tous deux au metier du repartiteur, du chauffeur, du receptionniste, 
voire meme du comptable. 

Comme le style d' architecture 3-tiers definit un moyen logiciel intermediate 
entre les applications clientes et les serveurs de base de donnees, il fournit au 
systeme les moyens techniques qui lui permettent de garantir des temps de 
reponse constants, quel que soit le nombre d'utilisateurs connectes. 



ETUDE DE CAS : SPECIFICATION DU STYLE D" ARCHITECTURE 3-TIERS 

La specification d'une architecture a composants metier 3-tiers implique des contraintes 
sur le modele d'exploitation. Une solution client/serveur 3-tiers entraine en effet la 
repartition des composants d'exploitation suivant les responsabilites : 

• le stockage des donnees sera reparti entre plusieurs instances de bases de donnees 
en central ou en agence. On a par ailleurs retenu un moteur de base de donnees rela- 
tionnel ; 
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• la distribution des services metier est realisee sur plusieurs composants metier dont 
le deploiement est a preciser. La technologie Java-RMI est arretee pour sa 
realisation ; 

• la presentation et la gestion des applications correspondent a differents composants 
d'exploitation repartis en central ou en agence. Ces applications seront developpees 
en Java et deployees sur les postes clients. Le serveur Web est une application 
particuliere qui a pour role de rendre accessible la situation des commandes aux diffe- 
rents clients de SIVEx. Elle sera realisee avec la technologie Java-applet ; 

• Integration des donnees et des processus complete I'architecture afin de permettre 
I'utilisation des progiciels du commerce et de faciliter leur cohabitation avec des 
developpements specifiques. La realisation de cette fonction technique s'appuie sur 
un outil EAI compose de serveurs de messages d'echanges {Message hub ou broker) 
et de connecteurs. 

La definition d'un composant, au sens UML du terme, n'est ni une classe, ni une technolo- 
gie, mais une partie de logiciel qui peut etre interchangeable, au sens ou I'emploie Indus- 
trie. Dans notre cas, il s'agit de ne montrer que les composants d'exploitation, par 
opposition aux composants de type « librairie » ou « package java » qui ne sont pas visi- 
bles de I'exploitant. 

On ne peut formaliser, a ce niveau d'etude, qu'une typologie de deploiement, ou seuls les 
differents types de composants d'exploitation du systeme SIVEx sont apparents. Ce 
modele precise les dependances entre types de composants et definit les stereotypes qui 
seront employes pour la suite du projet. Le recours a la propriete UML « number » permet 
de specifier le nombre d'instances de composants d'exploitation qui peuvent exister pour 
chacun des types. 
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Figure 5-3 : Specification d 'organisation du modele de deploiement SIVEx 
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EVOLUTION DU DIAGRAMME DE COMPOSANT EN UML 2 

Suite au schema de l'etude de cas precedente, il convient de faire differentes 
remarques quant a revolution de notation apparue avec UML 2.0. II s'agit en 
premier lieu du changement de notation d'un composant. 



Composant 
UML 2.0 



Ensuite, UML 2.0 permet d'affiner la relation de dependance entre compo- 
sants en precisant les interfaces fournies et requises. Dans notre exemple, un 
connecteur EAI dispose d'une interface de scrutation de messages (Broker 
Client) en provenance du broker, tel qu'illustre dans la figure ci-dessous. 
Inversement un composant EAI Broker discute avec des composants presen- 
tant ce type d' interface. De meme, le connecteur SAP fonctionne avec un 
composant presentant une interface RFC (technologie propre a SAP). 
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Enfin UML 2.0 permet d'exprimer la composition d'un composant. Dans 
notre exemple, un composant Struts (voir http://jakarta.apache.org/struts/ 
index.html) est compose d'une ou plusieurs actions et d'une servlet qui cen- 
tralise les requetes de l'utilisateur, tel qu'illustre dans la figure ci-dessous. 
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Elaboration du modele de specification logicielle 

Une fois que les specifications techniques et d' architecture sont exprimees, on 
peut s'interesser aux fonctionnalites propres du systeme technique en proce- 
dant a une specification logicielle. Dans ce cadre, on propose d'utiliser les cas 
d' utilisation de maniere differente que pour la specification fonctionnelle. 
C'est pourquoi nous avons introduit le concept d'exploitant et de cas d'utilisa- 
tion technique. 

EXPLOITANT 

L'exploitant est un acteur au sens d'UML, si ce n'est qu'il ne beneficie que 
des fonctionnalites techniques du systeme. 

Tout systeme informatique possede au minimum un exploitant qui est « l'utili- 
sateur du systeme ». II s'agit ici de l'utilisateur dans son sens le plus general, 
independamment des fonctions ou du metier qu'il realise au travers de l'appli- 
cation. Dans ce cadre, tout utilisateur se connecte au systeme ou consulte 
l'aide en ligne. Ce sont les fonctionnalites purement techniques dont il 
beneficie en tant qu' exploitant. 
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CAS D'UTILISATION TECHNIQUE 

Un cas d'utilisation technique est destine a l'exploitant. C'est une sequence 
d' actions produisant une valeur ajoutee operationnelle ou purement 
technique. 

Note : le concept de cas d'utilisation technique introduit dans ce livre est une 
proposition faite aux architectes logiciels et aux concepteurs de proceder a 
une phase d' analyse des comportements techniques du systeme. En effet, le 
comportement des logiciels developpes obeit trop souvent au style des deve- 
loppeurs qui participent a sa construction, sans qu'une concertation prealable 
n'ait ete etablie sur : les styles d' architecture, les frameworks employes et le 
vocabulaire utilise dans la documentation technique du produit. Cependant, 
la diffusion des standards techniques : J2EE, .Net, Apache/Struts, PHP, etc. 
tend a uniformiser les styles de conception et a amoindrir l'interet d'une cap- 
ture des besoins techniques aussi formalisee que dans cet ouvrage. 

Les cas d'utilisation techniques sont absolument distincts des cas d'utilisation 
de la branche gauche : ils ne produisent aucune valeur ajoutee fonctionnelle. 
La branche droite recouvre en effet tous les services techniques dont un utili- 
sateur beneficie, parfois meme sans s'en rendre compte. 

Un modele de specification logicielle est generalement construit en deux itera- 
tions. Le modele initial consiste a recenser les besoins des differents exploi- 
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tants du systeme et a en extraire les cas d'utilisation techniques. Lors de la 
deuxieme iteration, le modele de specification est reorganise en couches de 
responsabilites techniques de maniere a affiner les exigences. Cette derniere 
technique sera approfondie ulterieurement dans le chapitre. 



ETUDE DE CAS : IDENTIFICATION DES CAS D" UTILISATION 




Les exploitants du systeme SIVEX sont : 

• I'utilisateur, qui utilise une des applications du systeme SIVEx. La majorite des 
acteurs de la branche fonctionnelle sont done des utilisateurs dans la dimension tech- 
nique, 

• I'ingenieur d'exploitation, qui est charge de deployer et de depanner le systeme. 

Les cas d'utilisation techniques de SIVEx sont d'abord identifies en considerant I'attente 
operationnelle de chaque exploitant : 

• I'utilisateur va travailler avec des entites sous la forme d'objets, ce qui implique la 
mise en oeuvre des mecanismes de persistance et de gestion de cycle de vie des 
objets ; 

• certains utilisateurs vont beneficier d'applications du commerce afin d'accelerer le 
deploiement de SIVEx. Les objets qu'ils utilisent implicitement au travers de ces pro- 
giciels doivent etre synchronises avec ceux qui sont enregistres dans les bases de 
donnees SIVEx. En consequence, un mecanisme d'EAl doit etre mis en ceuvre pour 
permettre aux differents utilisateurs de partager les memes donnees quelle que soit 
I'application qu'ils utilisent ; 

• plusieurs utilisateurs peuvent travailler en parallele. L'integrite est le mecanisme qui 
em-peche la mise a jour simultanee d'une meme entite par deux utilisateurs diffe- 
rents ; 

• chaque utilisateur beneficie egalement d'une gestion des charges au niveau du ser- 
veur. Ainsi, les temps de response du systeme ne s'en trouvent pas degrades en fonc- 
tion du nombre d'utilisateurs connectes ; 

• I'utilisateur doit se connecter et etre reconnu du systeme pour pouvoir y travailler. 
L'authentification est le mecanisme qui protege le systeme des intrusions externes ; 

• chaque utilisateur doit disposer d'une aide contextuelle qui I'aide a exploiter le sys- 
teme de la maniere la plus efficace ; 

• le systeme doit etre exploitable ; a ce titre, il faut qu'il soit en mesure de generer des 
traces et des alertes qui vont faciliter sa maintenance au sein du systeme informati- 
que global de I'entreprise. C'est cette analyse technique du probleme qui permet 
d'introduire I'ingenieur d'exploitation comme autre exploitant du systeme ; 

• I'ingenieur d'exploitation ainsi que I'utilisateur sont soumis a des regies de securite. 
Dans un systeme client/serveur ces aspects recouvrent l'authentification, I'habilita- 
tion, le cryptage, la non-repudiation et I'audit. 

L'ensemble des cas d'utilisation cites ici ne sont pas specifiques a SIVEx. Leur position en 
branche droite en fait des problemes recurrents aux systemes client/serveur. Ces con- 
traintes d'utilisation techniques donnent lieu a un premier modele de specification logi- 
cielle represente par un diagramme de cas d'utilisation. 
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Figure 5-4 : Modele de specification logicielle de SIVEx 

Dans le modele initial de specification logicielle, chaque cas d'utilisation est sommaire- 
ment detaille suivant la meme technique que celle decrite au chapitre 4 comme I'illustre 
I'exemple 5-1. Les informations du modele de specification fonctionnelle servent a justi- 
fier les besoins qui vont etre exprimes dans le cas d'utilisation technique. 

Cas d'utilisation : manipuler des objets 



Intention 


I'utilisateur desire agir sur le cycle de vie d'un ou plusieurs 




objets. 


Actions 


creer, modifier, supprimer un objet ou un graphe d'objets. 


Identification du besoin 


gestion des commandes. 


Exemple 


le receptionniste gere le cycle de vie d'une commande qu'il 




cree, modifie ou supprime. II manipule egalement en une 




seule fois I'ensemble des colis decrits par la commande. 



Tableau 5-1 : Definition initiale d'un cas d'utilisation technique 



Organisation du modele de specification logicielle 

A F usage, le modele de specification logicielle obtenu est trop sommaire pour 
initier une specification technique suffisamment detaillee. Tous les cas d'utili- 
sation tels que « manipuler des objets » concernent differentes responsabilites 
de traitement qui vont de 1' interface utilisateur a la base de donnees. Dans ce 
contexte, il est difficile de pouvoir preciser de maniere detaillee les comporte- 
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ments techniques attendus, si Ton n' organise pas la specification suivant les 
differentes responsabilites de traitement. 



COUCHE LOSICIELLE 

Une couche logicielle represente un ensemble de specifications ou de reali- 
sations qui respectivement expriment ou mettent en ceuvre un ensemble de 
responsabilites techniques et homogenes pour un systeme logiciel. 

Les couches s'empilent en niveaux pour couvrir des transformations logi- 
cielles successives, de sorte que la couche d'un niveau ne puisse utiliser que 
les services des couches des niveaux inferieurs. 



Le recours aux couches logicielles va nous permettre d'affiner la specification 
technique en divisant le probleme en sous-parties specialisees. Notre point de 
depart consiste a considerer le role et la description des cinq couches logi- 
cielles illustrees par la figure 5-5. Cette organisation correspond au style 
d' architecture en couches preconise pour le developpement d'une solution 
client/serveur [Rumbaugh 91]. 
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Figure 5-5. : Style d'architecture en 5 couches 



Dans le modele UML, les couches logicielles correspondent a des packages. 
Pour preciser leur specificite, nous avons introduit le stereotype « layer ». Ces 
packages contiennent des cas d' utilisation techniques qui ne sont plus force- 
ment pilotes par un des exploitants du systeme. A chaque fonction observable 
pour l'exploitant, correspond en effet une cascade de responsabilites techni- 
ques qui se deploient sur les differentes couches logicielles. Chaque couche 
produisant des services pour les niveaux superieurs contient en consequence 
des cas d'utilisation pilotes par les couches exploitantes. 
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COMPLETEZ LES COUCHES PAR DES PARTITIONS 

Le style d' architecture en 5 couches est une recommandation qui doit etre 
appliquee au contexte du systeme en developpement. A un meme niveau, il 
est cependant possible de repartir les responsabilites techniques en parti- 
tions. Une partition correspond a plusieurs packages independants, mais au 
meme niveau de responsabilites. 

Une partition apparait lorsqu'une meme couche est concernee par differentes 
technologies ou lorsque le systeme communique avec d'autres systemes par 
des mecanismes specifiques. 



ETUDE DE CAS : ORGANISATION EN COUCHES DU MODELE 
DE SPECIFICATION 



«1ayer» 
Presentation 



I 



«layer» 
Application 
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«layer» 
Synchronisation du SI 
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Metier 
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«layer» 
Acces aux donnees 



I 

V 



«layer» 
Stockage des donnees 



Figure 5-6. : Organisation du modele de specification logicielle (diagramme de packages) 

Le style d'architecture en 5 couches structure le modele de specification logicielle. Les couches 
s'organisent suivant les dependances qui s'etablissent entre elles. Pour gerer la problematique 
des interfaces avec les systemes ERR CRM et plus largement avec les autres composantes du 
systeme d'information, I'architecte technique a ajoute une partition au niveau de I'application qui 
permet de synchroniser le systeme SIVEx avec le reste du systeme d'informations de I'entreprise. 
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Developpement des couches logicielles 

Dans le cadre de la responsabilite affectee a chaque couche, une identification 
poussee des cas d' utilisation techniques permet de poser de maniere plus 
precise des problemes a traiter. D'une part, les cas d' utilisation techniques 
peuvent se specialiser suivant les couches sur lesquelles ils vont s'executer ; 
d' autre part, de nouveaux cas d'utilisation peuvent apparaitre pour repondre a 
la particularite d'une des couches. 

Le cas de SIVEx offre une illustration de ces differents cas : « Manipuler des 
objets » va donner lieu a plusieurs cas d'utilisation qui vont s'enchainer 
depuis la couche de presentation jusqu' a la couche d'acces aux donnees. Par 
ailleurs, pour manipuler des objets, il est necessaire de gerer des transactions 
avec la base de donnees relationnelle. II s'agit done d'un nouveau cas d'utili- 
sation specifique pour la couche de stockage des donnees. 

On utilise des relations de dependances entre cas d'utilisation pour formaliser 
les echanges des couches clientes aux couches fournisseuses. Parce qu'elles 
traduisent une delegation d'un cas d'utilisation vers F autre, nous avons intro- 
duit le stereotype « delegate ». 



ETUDE DE CAS : DEVELOPPEMENT DE LA COUCHE « ACCES 



Les cas d'utilisation d'une couche logicielle s'identifient par rapport aux services attendus 
par les couches exploitantes. Dans ce cadre, chaque dependance « delegate » repre- 
sente une relation de client a fournisseur entre couches. 

Pour obtenir une specification technique detaillee du systeme, I'architecte technique a 
choisi de recourir aux delegations suivantes : 

• rechercher un objet au niveau de la presentation necessite de s'appuyer directement sur 
I'exploitation du schema de donnees d'une classe au niveau de la couche d'acces aux 
donnees ; 

• executer un service au niveau de la couche metier repose sur I'exploitation de reque- 
tes specifiques au niveau de la couche d'acces aux donnees, qui utilise systematique- 
ment la gestion des transactions. 

Notez bien qu'il s'agit ici d'un decoupage qui permet a I'architecte de specifier ses 
besoins techniques avant de les concevoir. Ce n'est done en rien I'amorce d'une concep- 
tion qui serait ici purement fonctionnelle. Par ailleurs, d'autres decoupages permettent 
d'obtenir une qualite de specification equivalente. 
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"N. s'appuie sur ^ 

\. )* « (delegate >> j 

Presentation::Rechercher un objet 77 

Exploiter une classe 



se synchronise avec \ 

delegate» «include» 




Metier::Gerer le cycle de vie d'un objet 

A 

Gerer les transactions 
«include» ?f 

«include» 

O 3^ S 
«delegate» "x ^ 

Metier::Executer un service Exploiter une requete 

Figure 5-7 : Structure de la couche d'acces aux donnees 



Definition des concepts techniques 

Rappelez-vous qu'un bon modele est un modele qui colle a la realite. Le domaine 
technique possede egalement sa realite qui correspond d'une part a Fensemble 
des outils mis en ceuvre et d'autre part a l'aptitude de l'exploitant a s'interfacer 
avec le systeme, manipuler des objets, partager et stocker rinformation. 

Chaque couche comporte un vocabulaire specifique correspondant a la description 
du point de vue technique qu'elle represente. Le tableau ci-apres fournit un aper9U 
des diffeients concepts utilises au niveau de chacune des couches. La definition 
des termes employes sera precisee dans les explications ulterieures. 



Couche logicielle 



Representation 



Concept manipule 



Presentation 
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Couche logicielle 



Synchronisation du SI 



Metier 



Representation 



Concept manipule 



Formats pivots 
Transformations 
Transcodage 
References croisees 



Objet metier 

Objet composite 

Donnees reduites d'identification 



Acces aux donnees 



Metaclasse 
T-uplet 



Stockage des donnees 



Table 

Cle etrangere 



Conseil 



Tableau 5-2 : Exemples de concepts manipules suivant les couches 

Dans ce contexte, il parait evident que chaque couche recourt a des concepts 
distincts pour lesquels il convient de specifier une terminologie precise au sein 
d'un dictionnaire des termes techniques. 

ETABLISSEZ UN DICTIONNAIRE DE TERMES TECHNIQUES 

Lorsque plusieurs architectes et concepteurs participent a la specification 
technique, il existe un risque important d' incoherence entre les termes tech- 
niques, alors qu'une terminologie precise est indispensable a l'elaboration 
d'une architecture technique. II est done impossible de developper une speci- 
fication logicielle detaillee, sans recourir a la definition des termes techni- 
ques qu'un projet doit utiliser. 

En ce qui concerne la gestion des commandes dans SIVEx, nous trouverons 
en principe : 

au niveau de la couche presentation : un panneau de presentation des com- 
mandes deja prises dans une agence, un panneau de liste de commandes, 
un panneau d' edition d'une commande, des panneaux de detail pour les 
descriptions de colis, les adresses, les sites, les conditions tarifaires, etc ; 
au niveau de la couche application : un objet composite construit sur les 
classes d' analyse Commande, Colis et Site necessaire a l'edition complete 
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d'une commande et de ses liens, une liste de commandes classees par 
agences de distribution et sites, des libelles caracteristiques qui permettent 
de selectionner de maniere univoque un objet dans une liste et que Ton 
compose generalement a partir d'une liste reduite de donnees de l'objet ; 
au niveau de la synchronisation du SI : des echanges entre applications 
realises sur la base de formats pivots, des transformations aux formats 
attendus par les applications, des transformations de codes qui demandent 
generalement la mise en ceuvre de tables de correspondance et des referen- 
ces croisees qui permettent d'assurer l'unicite des objets references par des 
cles differentes dans chacun des progiciels concernes ; 
au niveau metier : un objet metier distribuant la commande et ses colis, un 
objet metier permettant d'acceder aux sites, un objet metier permettant 
d'acceder aux agences ; 

au niveau de 1'acces aux donnees : une classe technique qui gere 1'acces 
aux donnees pour chaque classe d' analyse Commande, Colis, Agence, 
Site, etc. Puisque cette classe represente les donnees d'une classe d' ana- 
lyse, nous l'avons qualifiee de metaclasse. Une classe t-uplet represente 
l'ensemble des valeurs d'une ligne de resultats en reponse a une requete de 
selection de donnees ; 

au niveau du stockage des donnees : des tables pour stocker les donnees de 
chaque classe et des cles etrangeres pour y acceder. 

Nous voyons ainsi comment les classes d' analyse vont se multiplier en diffe- 
rentes entites suivant les couches de conception. Si Ton considere de plus le 
besoin de regrouper les classes d' analyse Commande, Colis, Agence et Site dans 
un meme panneau de presentation, on comprend mieux dans quelle mesure les 
besoins specifiques a une couche necessitent de manipuler des composites ne 
correspondant pas forcement aux seules classes du modele d' analyse. 

On est done loin de la vision naive qui consiste a croire qu'une classe 
d' analyse produit systematiquement une classe de conception a perimetre 
identique dans chacune des couches. C'est meme rarement le cas tant les 
besoins de presentation, de distribution et de stockage agregent souvent les 
classes en paquets rendus insecables pour des raisons de performance. Chaque 
couche doit done gerer separement des concepts qui vont servir a decrire les 
cas d'utilisation techniques, dans la mesure oil le perimetre de responsabilites 
est forcement different d'une couche a 1' autre. 

Description d'un cas d'utilisation technique 

La description d'un cas d'utilisation technique est analogue a celle des cas d'utili- 
sation de la specification fonctionnelle. Dans ce cadre, on utilise un premier 
niveau de description, compose d'une fiche textuelle et d'un diagramme d'activite. 
Un second niveau de description objet complete eventuellement la specification. 
On utilise alors un diagramme de classes et un diagramme d' interaction. 
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Les concepts utilises pour decrire les cas d'utilisation appartiennent a la 
couche logicielle considered et font l'objet d'une definition dans le diction- 
naire des termes techniques. A titre d' illustration, sachez que Ton distingue le 
concept « Objet » suivant son appartenance a la couche « Acces aux donnees » 
ou a la couche « Metier ». 



ETUDE DE CAS : DESCRIPTION D'UN CAS D'UTILISATION TECHNIQUE 

Voici la description detaillee du cas d'utilisation « Acces aux donnees::Exploiter une 
classe ». Par analogie avec ce qui est presente au chapitre 4, on retrouve ici les rubri- 
ques de pre- et post-conditions ainsi que la description des enchainements. 

Couche logicielle : Acces aux donnees. 
Titre du cas d'utilisation : Exploiter une classe. 

But : Le metier necessite de charger, de repertorier et de sauvegarder une ou plusieurs ins- 
tances d'une meme classe. 

Resume : Repertorier plusieurs instances, charger ou sauvegarder une instance. 
Exploitants et/ou couches exploitantes : 

• la couche application lors d'une recherche d'objets ; 

• la couche metier lors de I'exploitation des donnees de plusieurs instances particulieres. 
Tableau 5-3 : En-tete du cas d'utilisation technique « Acces aux donnees::Exploiter une classe » 

Preconditions : 

Neant. 

Enchainements : 

Ce cas d'utilisation survient lorsque la couche de presentation souhaite rechercher ou pre- 
senter les donnees representatives d'une iiste d'objets, ou lorsque la couche metier desire 
synchroniser les objets avec leur systeme de persistance en SGBDR. 

Enchafnement (a) renseigner le critere 

Lorsque Taction de chargement, de suppression ou de modification concerne plusieurs ins- 
tances, les demandes s'accompagnent d'un critere qui est exploite par la metaclasse pour 
produire la requete necessaire. 

Chaque critere s'accompagne lui meme d'un t-uplet precisant les valeurs de reference ou de 
seuil a utiliser pour la requete. 

Enchafnement (b) charger des objets 

La couche metier demande le chargement d'instances a la metaclasse correspondante sui- 
vant un critere specifie. 

Enchafnement (c) supprimer des objets 

La couche metier demande la suppression d'instances a la metaclasse correspondante sui- 
vant un critere obligatoirement specifie. 
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Enchafnement (d) modifier des objets 

La couche metier demande la modification d'instances a la metaclasse correspondante sui- 
vant un critere imperativement specifies. Cet ordre s'accompagne obligatoirement d'un t- 
uplet fixant les valeurs d'entree de la modification demandee. 

Si le critere porte sur un identifiant nul, la demande sera interpretee comme une creation ; I'iden- 
tifiant du nouvel objet sera retourne. Dans tous les autres cas, il s'agira d'une mise a jour. 

Enchafnement (e) charger une liste de I i belles 

La couche de presentation demande une liste de donnees - les donnees reduites - afin de 
construire les libelles permettant a I'utilisateur d'identifier un objet unique pour chaque item 
presente. Chaque groupe de donnees est accompagne de I'identifiant de I'objet correspon- 
dent. Ce mecanisme permet a la couche presentation de synchroniser les selections de I'uti- 
lisateur avec la couche metier. 

Si le volume d'informations en retour depasse le seuil de limitation reseau (par exemple 1 Ko 
en cas de ligne bas debit), le nombre de donnees reduites renvoyees est limite. Un indicateur 
de limitation est egalement retourne. La couche de presentation peut alors demander a rece- 
voir la suite de la liste. 

Enchafnement (f) produire et exploiter la requete 

La metaclasse a pour role de produire et d'exploiter la requete necessaire avec le cas d'utili- 
sation « Gerer les transactions ». Dans tous les cas, un code d'erreur est retourne en cas 
d'echec de synchronisation avec le SGBDR. Dans le cas d'un chargement, les donnees sont 
renvoyees sous la forme d'une liste de t-uplets. 

Exceptions : 

Neant. 

Post-conditions : 

Les seuils de limitation reseau ne sont pas depasses pour les requetes qui concernent la 
couche de presentation. 



Tableau 5-4 : Corps du cas d'utilisation technique 
« Acces aux donnees::Exploiter une classe » 

Au meme titre que ce qui a ete realise pour les cas d'utilisation de la branche gauche, un 
diagramme d'activite, un diagramme de classes et un diagramme d'interaction peuvent etre 
developpes pour recapituler les specifications du cas d'utilisation. 
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Figure 5-8 : Diagramme d'activite du cas d'utilisation technique « Acces aux donnees::Exploiter 

une classe » 

Le diagramme des classes participantes aide a la definition des concepts techniques utili- 
ses pour decrire le cas d'utilisation technique. Nous vous rappellons que chaque classe 
doit etre definie dans le dictionnaire des termes techniques. 
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Figure 5-9. : Classes du cas d'utilisation technique « Acces aux donneesr.Exploiter une classe » 



Un diagramme de communication concourt a preciser la place et la responsabilite des concepts 
les uns par rapport aux autres dans le cas d'utilisation technique. 
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Figure 5-10. : Diagramme de communication du cas d'utilisation technique « Acces aux 
donnees:: Exploiter une classe » 



Ne pas faire 



NE CODEZ PAS AVANT DE CONCEVOIR 

II resulte de la description d'un cas d'utilisation technique un modele naif, 
qui ne fait que refleter l'idee de Farchitecte lorsqu'il specifie les problemes 
techniques. Les diagrammes UML developpes ne sont done qu'une facon 
d'exprimer un probleme, ils ne constituent pas une solution. 

Si nous implementions les classes telles qu'elles sont identifiees dans les cas 
d'utilisation techniques, nous passerions a cote d'un veritable travail de con- 
ception : 

il n'y aurait pas de recherche de composants existants a reutiliser ; 
aucune recherche d'optimisation ne serait realisee ; 
les concepts seraient melanges et on obtiendrait des classes concentrant 
trop de responsabilites, e'est-a-dire un code objet lourd a maintenir. Ce 
serait le syndrome des classes obeses. 

Par ailleurs, le modele de specification technique non encore bien defini 
reste nettement plus facile a corriger qu'un modele de conception. 
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Phases de realisation 
en capture des besoins 
techniques 



La capture des besoins techniques est une etape de prise en compte des 
contraintes techniques et logicielles. Elle doit etre suffisamment detaillee pour 
permettre d'aborder la conception generique du systeme. 

Le processus de construction mis en ceuvre dans F etape est le suivant : 

1 . Capture des specifications techniques liees a la configuration materielle : 
identifier les contraintes techniques liees aux machines, aux connexions et 
aux deploiements existants ; 

produire le diagramme de configuration materielle ; 

identifier les contraintes d' organisation specifiers par les choix d'architecture. 

2. Capture initiale des specifications logicielles : 

identifier les besoins logiciels du point de vue des exploitants ; 
elaborer la description sommaire des cas d'utilisation techniques. 

3. Specification logicielle detaillee : 
identifier un decoupage en couches logicielles ; 

identifier les cas d'utilisation techniques pour chaque couche ; 
elaborer la description detaillee des cas d'utilisation techniques. 




techniques detailles Coucnes 
logicielles 



Figure 5-11 : Construction de I'etape de capture des besoins techniques 



Chapitre Decoupage en 





Objectifs du chapitre 



Ce chapitre traite du demarrage de F analyse objet du systeme a realiser. 

Nous verrons en particulier comment utiliser la notion de package pour definir 
des categories de classes d' analyse et decouper le modele UML en blocs logi- 
ques les plus independants possibles. 

Cette structuration logique sera ensuite affinee durant toute l'etape d' analyse, 
mais neanmoins restera pour le chef de projet un outil essentiel qui lui 
permettra d' organiser son processus de developpement. 



Le decoupage en categories constitue la premiere activite de l'etape d' analyse 
(il s'affine bien sur de maniere iterative au cours du projet). II se situe sur la 
branche gauche du cycle en Y et succede a la capture des besoins fonctionnels. 

En fin d' analyse des besoins, nous obtenons un decoupage fonctionnel 
exprime a travers les cas d' utilisation organises dans le modele de specifica- 
tion fonctionnelle. 

Pour passer a l'analyse, nous allons changer radicalement l'organisation du 
modele et nous fonder sur les principes de l'approche orientee objet, notam- 
ment sur celui d'encapsulation. A cet effet, nous allons passer d'une structura- 



Quand intervient le 
decoupage en categories ? 
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tion fonctionnelle via les cas d' utilisation et les packages de cas d'utilisation, 
a une structuration objet via les classes et les categories. 



Controintes 
fonctionnelles 



Analyse du domain? 



Analyse de I'application 



Specification 
fonctionnelle 
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Branche 
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Developpement du 
modele statique 
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technique 




Figure 6-1 : Situation du decoupage en categories dans 2TUP 



Elements mis en jeu 



Categorie, package, 
Dependance, importation, visibilite, 
Diagramme de packages, 
Generalisation, association, navigabilite, 
Diagramme de classes par categorie, 
Structuration logique. 



Notion de categorie 

La classe represente une entite de structuration trop petite des lors qu'on 
s'attaque a un projet reel. Au-dela d'une douzaine de classes, il est utile de 
regrouper les classes fortement couplees en unites plus grandes. Le couplage 
s'exprime a la fois structurellement par des associations, des agregations, des 
compositions ou des generalisations, mais aussi dynamiquement par les inte- 
ractions qui se produisent entre les instances des classes. Bien sur, plus le 
nombre de classes devient important, et plus cette structuration s'avere indis- 
pensable. G. Booch [Booch 96] a introduit le concept de categorie pour 
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nommer ce regroupement de classes qui constitue la brique de construction du 
modele structurel d' analyse. 

QU'EST-CE QU'UNE CATEGORIE ? 

Une categorie consiste en un regroupement logique de classes a forte cohe- 
rence interne et faible couplage externe. 

Le terme categorie n'appartient pas en standard au langage UML qui 
comporte en revanche le concept plus general de package. Pour notre part, 
nous avons conserve ce terme, afin de differencier les categories qui structu- 
rent un modele construit sur des classes, du concept plus generique de 
package. Nous representons graphiquement les categories comme des stereo- 
types de packages. 

I I 

«category» 
Mission 



Figure 6-2 : Representation graphique d'une categorie 

Decoupage en categories 

Le decoupage fonctionnel induit par les cas d' utilisation permet de trouver les 
classes fondamentales du projet par le biais des diagrammes des classes parti- 
cipantes. II faut cependant considerer que Ton a seulement identifie des 
classes candidates pour 1' analyse, et non les concepts metier stables de 
l'entreprise. En effet, les diagrammes des classes participantes capturent le 
vocabulaire employe dans les cas d' utilisation, mais chaque terme n'a pas 
encore fait l'objet d'une definition elaboree au vu du probleme de l'entreprise. 

Par consequent, ces premiers diagrammes de classes doivent etre reamenages 
pour qu'il soit possible de poursuivre l'analyse, car on rencontre systemati- 
quement les cas suivants : 

la meme classe candidate participe a plusieurs cas d' utilisation differents, 
car certains concepts manipules par les utilisateurs sont representatifs du 
metier de l'entreprise ; 

des classes candidates de noms differents ont les memes responsabilites et 
participent aux memes collaborations, surtout si l'etude des cas d'utilisa- 
tion a ete menee par differents analystes. Ainsi, il existe parfois plusieurs 
termes pour un meme concept. 



o 

Definition 
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Ces desavantages tiennent au fait que les concepts sont dilues dans les fonctions 
et ne represented pas la problematique que doit resoudre le logiciel. A l'inverse, 
une approche objet offre a Fanalyste la possibilite de consolider la definition des 
concepts, en termes de representation a la fois structurelle et comportementale, 
puis de reutiliser ces definitions. Le decoupage initial fonctionnel doit done etre 
remis en cause si Ton veut profiter des benefices de F approche objet ; le decou- 
page en categories devient alors la base du modele structurel d' analyse. 

Si Ton entre dans le detail, on s'apercoit que les objectifs du decoupage en 
categories sont multiples et souvent cruciaux pour la reussite du projet. En 
phase d' analyse, on peut repertorier les objectifs suivants : 

organiser les equipes d'analystes, puisqu'elles vont pouvoir travailler sur 
des ensembles coherents et faiblement couples. La coherence implique le 
regroupement par competence metier, et la diminution du couplage intro- 
duit la possibilite d'un travail en parallele sur differents modules ; 

maltriser la complexite par la structuration, puisque Ton va pouvoir isoler 
les mecanismes de detail dans les categories et faire ressortir les collabora- 
tions d'ensemble au niveau de l'organisation du modele structurel. La 
categorie constitue done une unite fondamentale de decomposition, qui 
servira les etapes ulterieures de 1' analyse : conception, gestion de configu- 
ration, estimation de projets et test ; 

assurer l'evolutivite et la facilite de maintenance, et favoriser la reutilisa- 
tion, en separant notamment les parties applicatives, qui varient avec cha- 
que projet et qui sont sujettes aux changements, des parties metier 
generalement plus stables et meilleures candidates a la reutilisation. 

Le decoupage en categories doit etre realise le plus tot possible dans la phase 
d' analyse, en particulier pour pouvoir organiser les equipes. Ce decoupage 
initial doit se fonder sur 1' ensemble des classes candidates identifiers durant 
la phase precedente (voir chapitre 4), mais egalement sur deux principes 
fondamentaux : coherence et independance. 

Le premier principe consiste a regrouper les classes semantiquement proches. 
Pour cela, il faut chercher la coherence avec les criteres suivants : 

finalite : les classes doivent rendre des services de meme nature aux utili- 
sateurs ; 

Exemple SIVEx : Mission et Etape. 

evolution : on isole ainsi les classes reellement stables de celles qui vont 
vraisemblablement evoluer au cours du projet, ou meme par la suite. On 
distingue notamment les classes metier des classes applicatives ; 

Exemple SIVEx : Facture et TransmissionComptable (decrivant un com- 
posite d'objets transmis vers le module CO de SAP). 
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cycle de vie des objets : permet de distinguer, et done de gerer differem- 
ment, les classes dont les objets ont des durees de vie tres differentes. 

Exemple SIVEx : Client et Commande. 

Le deuxieme principe consiste a renforcer ce decoupage initial en s'efforcant 
de minimiser les dependances entre categories. Ce second sujet sera detaille 
plus tard dans le chapitre. 



ETUDE DE CAS : PREMIER DECOUPAGE EN CATEGORIES DE SIVEX 

Une premiere repartition des classes decouvertes au chapitre 4 est illustree a la figure 6-3. Elle 
offre une vue globale des categories et des classes qu'elles contiennent 1 . Notez que UML 2.0 a 
officialise le terme « diagramme de packages » pour qualifier ce type de diagramme ne conte- 
nant que des packages. 

Concretement, chaque classe candidate a ete affectee a une seule categorie, conformement aux 
criteres enonces precedemment. Cela ne constitue bien sur qu'une premiere iteration de I'organi- 
sation du modele structurel, qui devra etre retravaille une fois les diagrammes de classes de 
chaque categorie affines. En effet, de nouvelles classes vont probablement etre introduites ; 
certaines pourront etre deplacees afin de minimiser les dependances entre categories. 
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Figure 6-3 : Premier decoupage en categories de SIVEx 



1. La notation de la figure 6-3 a ete proposee par l'outil Rational Rose. Elle consiste 
a repertorier les classes appartenant a chaque package a l'interieur du symbole 
graphique. Notez que le signe « + » devant les noms des classes signifie simplement 
« public », au sens : visible de l'exterieur du package. 
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Voici les raisons de ce premier decoupage : 

• les categories Reseau et Plan de Transport ont ete separees selon le critere d'evolution 
(Reseau est potentiellement realisable, voire achetable dans le commerce...) ; 

• la categorie Exploitation Informatique a ete isolee car elle correspond a un service technique 
classique dans toute application informatique (et done potentiellement reutilisable), mais 
pas a un service metier ; 

• les categories Comptabilite et Transmission Comptable sont distinctes en fonction des crite- 
res de finalite et de cycle de vie. On retrouve egalement la distinction entre classe metier : 
Facture, et classe applicative : TransmissionComptable ; 

• les categories Commandes et Clients ont ete separees selon le critere de cycle de vie, et 
aussi d'evolution. On espere en effet une grande reutilisabilite pour la categorie Clients. 



Conseil 



UNE CATEGORIE D'ANALYSE CONTIENT MOINS DE 10 CLASSES ! 
Une categorie ne doit etre ni trop grosse ni trop maigre ! 

Trop grosse : elle aura beaucoup de responsabilites differentes et ne 
pourra pas etre maitrisee par une equipe de taille raisonnable. 
Trop maigre : elle risque de ne pas avoir assez de responsabilites et de 
dependre alors de nombreuses autres petites categories. La dilution des 
responsabilites entraine generalement une multiplication des couplages. 



G. Booch recommandait deja dans [Booch 96] de decomposer un systeme en 
categories contenant une moyenne d'une douzaine de classes. Or, si nous 
faisons la moyenne des categories de SIVEx, nous obtenons seulement 4 
classes pour ce decoupage preliminaire. D'oii vient ce decalage ? N'oublions 
pas qu'il s'agit de classes candidates, issues d'une premiere iteration 
d' analyse. Or, les categories dont parle Booch sont des categories de concep- 
tion : elles ont subi de nombreuses iterations et incluent, en supplement, beau- 
coup de concepts techniques comme 1THM ou Faeces aux donnees, qui 
apportent nettement plus de classes (voir chapitres 9 a 11). 



Dependances entre categories 

Au chapitre 4, nous avons indique qu'un package (et done une categorie) 
constitue un espace de nommage, et qu'il peut contenir des elements UML, 
des diagrammes, voire d' autres packages. Cette relation de contenance est une 
relation de composition au sens UML. Cela signifie d'une part que tout 
element UML est declare et possede par un seul package. D' autre part, si le 
package est supprime du modele, tout element inclus est egalement detruit. 
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CATEGORIES ET IMPORTATION 



Outre posseder des elements, un package peut egalement importer des ele- 
ments visibles d'un autre package. Cela signifie que le deuxieme package a 
explicitement declare que certains de ses elements peuvent etre utilises par 
d'autres packages. UML definit ainsi deux niveaux de visibilite : 

public (+) : l'element est utilisable par tout package relie par une 
dependance ; 

private (-) : l'element n'est utilisable que par son package parent. 

En analyse, nous prefixerons simplement les classes visibles par le symbole 
« + ». 

La relation d' importation est representee en UML par une dependance du 
package client vers le package fournisseur. 

Nous allons illustrer ces differentes notions sur le schema suivant, qui montre 
quelques associations concernant la classe Mission et des classes d'autres 
categories. 



ETUDE DE CAS : ASSOCIATIONS DE LA CLASSE MISSION 



«category» 
Ressources 




«category» 
Missions 



Etape 



«category» 
Commandes 



est planifiee pour 



Figure 6-4 : Quelques associations concernant la classe Mission 

Les classes Mission et Etape, qui appartiennent a la meme categorie, ont acces I'une a I'autre au 
moyen de I'agregation. En revanche, les classes Mission et Commande ne peuvent acceder I'une a 
I'autre, car leurs categories respectives forment une cloison etanche entre elles. Pour que Mission 
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puisse acceder a Commande, il suffit cependant que la categorie Missions importe la categorie 
Commandes. Du meme coup, la classe Etape accedera aussi a Commande. Pareillement, pour que 
Mission puisse acceder a Chauffeur el Vehicule, il faut que la categorie Missions importe la categorie 
Ressources. Les relations entre les categories correspondantes sont decrites a la figure ci-apres. 

I ' 

«category» 

Missions 
♦ Mission 
+ Etape 





<<category» 
Ressources 


1 


+ Chauffeur 
+ Vehicule 



«category» 
Commandes 
♦ Commande 



Figure 6-5 : Exemple d'importations entre categories 



Notons que l'importation est une relation unidirectionnelle, qui offre un acces 
aux elements du package fournisseur pour les elements du package client. 
Done, meme si la categorie Missions importe la categorie Ressources, les 
classes Chauffeur et Vehicule n'ont toujours pas acces a la classe Mission. 
Cette difference vient du fait que 1' association est par defaut une relation bi- 
directionnelle entre classes. Nous allons maintenant detailler ce point. 




INFLUENCE DES RELATIONS ENTRE CLASSES SUR LES DEPENDANCES 
ENTRE CATEGORIES 



D'une maniere generate, rappelons que si le langage UML definit quatre 
types de relations entre classes (dependance, association, generalisation et 
realisation), nous n'utilisons en phase d'analyse que l'association et la gene- 
ralisation. Si Ton y regarde de plus pres, trois de ces quatre relations sont 
orientees ; seule l'association est par defaut bidirectionnelle. 

Lors du decoupage en categories, nous allons essayer de limiter au minimum 
le nombre de relations qui traversent les categories. En effet, des qu'une 
generalisation entre classes sort d'une categorie, une dependance de meme 
sens entre les categories parentes s'impose. Mais e'est encore pire pour les 
associations, puisque par defaut, elles vont dans les deux sens, et imposent 
done une importation mutuelle des deux categories parentes. 
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Etude 



Dans l'exemple ci-dessous, CI depend de C2, mais C2 ne depend pas de CI. 
En effet, si A specialise B, et done en depend, la reciproque n'est pas vraie. 
En revanche, C3 depend de C4, et C4 depend egalement de C3, car F associa- 
tion entre les classes C et D est bidirectionnelle. 




«oategory» 
C2 



1 




1 


«category» 
C3 


> 

<- 


«category» 
C4 


C 






D 















Figure 6-6 : Generalisation et association entre classes et dependance entre packages 

Le style d' architecture vise dans un projet est l'orientation composant, car 
nous en connaissons les benefices en termes de facilite de modularite, de 
maintenance, d'evolution et de reutilisation. C'est ce style qui influence ici le 
modele structurel d' analyse, car il demande de minimiser les dependances 
entre categories. Le but est de pouvoir definir, des ce stade, des composants 
d' analyse qui capitalisent les concepts metier d'une entreprise et sont 
reutilisables pour l'analyse d'autres projets. Dans un second temps, Forgani- 
sation du modele structurel pourra persister dans le modele logique de 
conception, et faciliter F identification des composants distribues (voir 
chapitre 10). 

Pour comprendre en quoi le couplage influence la qualite du developpement, 
et ce des Fetape d'analyse, nous comparons les deux situations du schema 
suivant. Supposons que Fon vous propose de devenir chef de projet sur PI ou 
P2. Si vous choisissez P2, c'est que vous aimez vraiment la difficulte ! En 
effet, eu egard aux dependances entre categories, le chef du projet PI pourra 
raisonnablement s'organiser de la facon suivante : 

concentrer d'abord les forces sur l'analyse de CI ; 

des que l'analyse de CI sera terminee, une partie des troupes basculera sur 
l'analyse de C2 et une autre partie sur celle de C3, qui pourront alors se 
derouler en parallele. 
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Son collegue malchanceux du projet P2 sait simplement qu'il aura un tres gros 
travail de consolidation et de communication a effectuer entre ses equipes... 




Figure 6-7 : Deux exemples de dependances entre categories (diagrammes de packages) 

L'analyste doit etre conscient qu'il existe plusieurs decoupages possibles. II se 
fonde sur les grands principes que nous avons enonces precedemment. Une 
fois son choix effectue, il est prescriptif au niveau des dependances entre cate- 
gories. En effet, il doit fixer des objectifs d' organisation et, eventuellement, de 
reutilisation. 

Le concepteur, en revanche, considere le modele d' analyse comme un 
ensemble d' exigences fonctionnelles a realiser. II ne pourra conserver les 
dependances que si ses choix de conception sont compatibles avec l'organisa- 
tion preconisee par l'analyste. Dans tous les cas, il devra finalement decrire les 
dependances reelles du modele de conception. 



LES DEPENDANCES ENTRE CATEGORIES PEUVENT SUIDER LE CHOIX DE 
NAVIGABILITE DES ASSOCIATIONS ! 

Une association entre deux classes A et B permet par defaut de naviguer 
dans les deux sens entre des objets de la classe A et des objets de la classe B. 
Cependant, il peut etre utile de limiter cette navigation a une seule des deux 
directions. C'est le cas pour les associations qui sortent des categories, sans 
quoi, nous recuperons systematiquement une paire de dependances. UML 
nous permet de representer explicitement cette navigabilite en ajoutant sur 
F association une flee he indiquant le seul sens possible. 



Meme si la navigabilite est le plus souvent liee a un choix de conception, et a 
des considerations d'efficacite, on peut l'utiliser avec discernement des 
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1' analyse, pour isoler les concepts appartenant a des categories differentes. 
L'exemple suivant va illustrer notre propos : la categorie Reseau a ete isolee 
precisement parce qu'elle contient des classes hautement reutilisables. Si Ton 
veut qu'elle ne depende pas des autres categories, les classes Parcours et 
Commune ne doivent en aucun cas avoir une quelconque connaissance des 
classes Connexion et ZoneTerminale. En UML, cela se traduit par la fleche de 
navigabilite sur les deux associations qui vont de la categorie Plan de Trans- 
port a la categorie Reseau. 



: 



<category» 
Plan de Transport 




Connexion 



ZoneRedistribution 



ZoneTerminale 



0. 1 



m e 




Figure 6-8 : Exemples de navigabilite d'association 

Plus generalement, les dependances souhaitees entre categories determinent 
les decisions relatives au sens des relations entre classes : associations, mais 
aussi generalisations, et par la suite en conception : dependances et 
realisations. 



ETUDE DE CAS : DIAGRAMME DE CLASSES PRELIMINAIRE 



Si nous prenons comme exemple la categorie Missions, le diagramme de classes preliminaire va 
comprendre : 

• les classes appartenant en propre a la categorie, c'est-a-dire celles qui apparaissaient deja 
a la figure 6-3 ; 
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=1 

«category» 
Missions 
+ Mission 
+ Enlevement 
+ Traction 

+ EvenementMission 
+ IncidentMission 
+ FeuilleDeRoute 
* FicheDeCommande 
+ Livraison 
+ Etape 



Figure 6-9 : Classes propres a la categorie Missions 

• les classes des autres categories reliees aux precedentes. Dans le diagramme de classes, 
une indication particuliere stipule qu'elles n'appartiennent pas a la categorie courante. Elles 
figurent dans ce cas sous leur nom complet, par exemple : « Ressources::Agence » ; cer- 
tains outils CASE (comme Rational/Rose) ajoutent une mention de type « from PackageXXX 
», eventuellement renforcee par I'utilisation d'une couleur differente. 




Figure 6-10 : Diagramme de classes preliminaire de la categorie « Missions » 

Le diagramme precedent montre qu'il existe des associations qui sortent de la categorie Mis- 
sions, et qui concernent egalement les categories Ressources et Commandes. Or, I'analyste a 
fait le choix suivant de dependances entre ces categories : 
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<category» 
Missions 



«category» 
Commandes 



«category» 
Ressources 



Figure 6-11 : Objectifs de dependance de la categorie Missions 

Nous devons done limiter la navigabilite de ces associations pour nous conformer au choix de 
dependances entre categories. Par exemple : 

• chaque objet Mission doit connaTtre les ressources qui lui ont ete affectees, ainsi que son 
Agence responsable, mais non I'inverse ; 

• chaque objet Mission doit connaitre les Commandes qu'il traite, mais non I'inverse. 
Le diagramme de classes de la categorie Missions devient alors : 




Commande 
ifrom Commandes) 



FeuilleDeRoute 1 



FicheOeCommande 



Figure 6-12 : Diagramme de classes de la categorie Missions avec les navigabilites 
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LES DEPENDANCES ENTRE CATEGORIES NE SONT PAS TRANSITTVES ! 

On entend par relation transitive, la propriete de propagation d'une relation 
de type « est superieur a » : ainsi si A > B et B > C, on peut en deduire que 
A > C. La relation « est une sous-classe de » est un exemple de relation tran- 
sitive entre classes. Les dependances entre categories ne sont pas transitives. 
Par exemple, Missions importe Commandes, et Commandes importe Clients. 
Cela ne signifie pourtant pas que Missions a un acces direct a Clients. Cette 
non-transitivite des dependances entre categories est precieuse puisqu'elle 
permet d'eviter une propagation anarchique des modifications dans toute 
F application. A chaque niveau, les categories forment une sorte de rempart 
contre les modifications, permettant ainsi aux systemes d'etre plus evolutifs 
et maintenables. 



ETUDE DE CAS : AUTRES DIAGRAMMES DE CLASSES PRELIMINAIRES 

Pour illustrer plus avant les principes de ce chapitre, nous indiquons ci-apres quelques diagram- 
mes de classes preliminaires des categories de SIVEx. Sur les schemas, les classes importees 
sont en blanc tandis que la classe consideree comme centrale pour la categorie apparait en 
fonce. 





Utilisateur 
(from Exploitation Informatiquet 



Figure 6-13: Diagramme de classes preliminaire de la categorie Ressources 
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EnCoursDeCmd 



Colis <: 



1..* 



Agence 



Receplionniste 



decrif 1 




Commande 




livraison 



Client 

(from Clients) 



enlevement 



Site 
(from Reseaul 



Figure 6-14 : Diagramme de classes preliminaire de la categorie Commandes 



Utilisateur 

(from Exploitation Informatique) 







possede 






Client I 




Compte 




— I 1 




0.1 



Site 

(from Roseau) 



Figure 6-15: Diagramme de classes preliminaire de la categorie Clients 

Le dernier schema de la serie represente ainsi I'etat preliminaire des dependances souhaitees 
entre les categories au debut de la phase d'analyse. C'est un diagramme de packages au sens 
UML2.0. 
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<<category» 
Transmission 
Comptable 



«category>> 
Comptabilite 



«category» 
Plan de 
Transport 



1 




1 


<<category>> 
Missions 


-> 


«category» 
Comma ndes 





«category» 
Ressources 



■A 



<<category>> 
Colis 



«category» 
Roseau 



<category> 
Clients 



«category» 
Exploitation 
Informatique 



Figure 6-16: Diagramme de packages d'analyse 



Phases de realisation du 
modele structurel d'analyse 

En resume, le decoupage en categories constitue la premiere activite de l'etape 
d'analyse. C'est a ce moment-la qu'on reporte la definition des classes candi- 
dates provenant du modele de specification fonctionnelle au modele structurel 
contenant les classes et les categories de 1' analyse. Une categorie consiste en 
un regroupement logique de classes a forte coherence interne et faible 
couplage externe. Nous la representons par un stereotype de package. 

En analyse, pour identifier les bonnes categories, il faut se fonder sur deux 
principes fondamentaux : coherence et independance. Un bon decoupage 
permet d'etre plus efficace pour organiser les equipes, maitriser la complexite, 
assurer l'evolutivite et favoriser la reutilisation. En d'autres termes, le 
decoupage conditionne 1' application du style d' architecture oriente compo- 
sant. La recherche de limitation des dependances entre categories impose 
egalement des contraintes aux relations entre classes. 
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La demarche mise en ceuvre dans ce chapitre est synthetisee par la figure suivante : 




Figure 6-17 : Demarche d'elaboration du modele structure! 



Chapitre Developpement 
7 du modele statique 



Objectifs du chapitre 

Ce chapitre va nous permettre d'illustrer les principales constructions du 
diagramme de classes UML durant Fetape d' analyse. 

Le diagramme de classes a toujours ete le diagramme le plus important dans 
toutes les methodes orientees objet. C'est egalement celui qui contient la plus 
grande gamme de notations et de variantes. UML a reussi a unifier le vocabu- 
laire et les concepts sans perdre la richesse et les apports des differentes 
methodes existantes. 



Quand intervient 
le developpement 
du modele statique ? 

Le developpement du modele statique constitue la deuxieme activite de 
l'etape d'analyse. Elle se situe sur la branche gauche du cycle en Y et succede 
au decoupage en categories. Les diagrammes de classes etablis sommairement 
dans les DCP (diagrammes des classes participantes du chapitre 4), puis 
reorganises lors du decoupage en categories (chapitre 6), vont etre detailles, 
completes, et optimises. 

II s'agit d'une activite iterative, fortement couplee avec la modelisation dyna- 
mique, decrite au chapitre suivant. Pour les besoins du livre, nous avons 
presente ces deux activites de fa5on sequentielle, mais dans la realite elles 
sont effectuees quasiment en parallele. 
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Branche Branche 
fonchonnelle technique 




Figure 7-1 : Situation du developpement du modele statique dans le 2TUP 



Elements mis en jeu 

Classe, responsabilite, 

Association, multiplicity, agregation, composition, 

Attribut, attribut derive, attribut de classe, 

Classe d' association, qualificatif, 

Operation, operation de classe, 

Classification, generalisation, specialisation, 

Classe abstraite, principe de substitution, generalisation multiple, 

Contrainte. 

Affiner les classes 

Les classes identifiers lors de F etude des cas d' utilisation (chapitre 4), puis 
reparties dans les categories (chapitre 6), sont simplement des classes candi- 
dates pour 1' analyse objet. II convient desormais de les examiner de maniere 
detaillee, d'en eliminer certaines, ou au contraire d'en ajouter d'autres. Cette 
activite de validation est iterative ; l'affinement des associations, ainsi que 
l'ajout des attributs et des operations, vont nous fournir de precieuses infor- 
mations. 

On peut cependant des a present repertorier quelques principes generaux pour 
eliminer les classes qui n'en sont pas : 

classes redondantes : elles representent le meme concept ; 
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Exemple SIVEx : si plusieurs analystes avaient travaille en parallele, on 

aurait pu trouver les classes redondantes Vehicule et Camion, EnCours- 

DeCmd et SuiviCommande, IncidentMission etAlarme, etc. 

classes vagues : elles ne correspondent pas a des concepts que Ton peut 

exprimer par des classes. Ainsi, des termes tels que « organisation des 

reseaux » ou « configuration des etapes » sont trop generaux et ne sont pas 

suffisamment precis pour justifier la creation d'une classe ; 

classes a la place d'attribut : elles expriment des concepts quantifiables ; 

Exemple SIVEx : pas de classe Poids, ce n'est qu'un attribut de Colis. 
classes a la place d'un role : elles expriment un role dans une association 
particuliere ; 

Exemple SIVEx : dans la categorie Ressources, la notion d'agence princi- 
pal est representee par un role d' association entre les classes ZoneRedis- 
tribution et Agence, et non par une classe a part entiere. 
classes representant des acteurs : souvent utiles, mais uniquement lorsque 
le systeme gere des informations sur l'acteur ; 

Exemple SIVEx : dans la categorie Ressources, on ne trouve pas la classe 
Repartiteur, contrairement aux autres acteurs. En effet, elle semble inutile, 
alors qu' OperateurQuai est utilisee dans Colis, Receptionniste dans Com- 
mandes, et Chauffeur dans Missions. 

classes de conception : elles introduisent trop tot des choix de realisation. 
Ainsi, le concept « fichier client » n' a pas de sens dans le metier, bien 
qu'integre au jargon des utilisateurs ; 

classes representant des groupes d'objets : elles sont inutiles, car implici- 
tes dans les multiplicites des associations, et font souvent reference a des 
choix de conception. 

Exemple SIVEx : on ne trouve pas dans le modele d' analyse de classe 
ListeCommandes ou ListeColis. Ces groupes d'objets sont implicites dans 
les associations entre Mission et Commande, et entre Commande et Colis. 

De la meme facon, on peut indiquer quelques principes afin d'optimiser le 
modele structurel. Cela conduit tantot a ajouter des classes manquantes, tantot 
a subdiviser une classe existante en plusieurs : 

une classe ne doit pas avoir trop de responsabilites, il en resultera sinon un 
nombre eleve d' associations, d'attributs ou d'operations. II est done prefe- 
rable de la decouper en ensembles plus petits et homogenes en termes de 
responsabilites et de cycles de vie ; 

ne pas confondre objet physique et objet logique : autrement dit une entite 
et sa description. 

Ces deux principes sont illustres dans F etude de cas ci-apres. 
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ETUDE DE CAS : SEPARATION DE RESPONS A BILITES 

Dans la categorie Commandes, nous avons isole une classe EnCoursDeCmd a laquelle la classe 
Commande delegue le suivi reel des dates d'enlevement et de livraison, ainsi que des dates de 
depart et d'arrivee dans les agences. Nous sommes amenes de la meme fagon a separer le 
SuiviMission de la Mission, pour traiter tous les aspects lies au suivi en temps reel des evenements. 

Nous avons identifie au chapitre 4 (voir la figure 4-16) I'association decrit entre Commande et 
Colis. En fait, une commande contient initialement la description de chacun des colis prevus, 
puis au cours d'une mission, chaque colis reel est identifie et rattache a une commande. II faut 
done distinguer deux classes differentes : DescriptionColis et Colis, qui ne component ni les 
memes responsabilites, ni les memes etats. 

Notez egalement que les multipliers des associations ont ete affinees, pour que les cas degra- 
des, tels que la possibility d'egarer des colis, soient pris en compte. 




Figure 7-2 : Modification de la relation entre Commande et Colis 



Affiner les associations 

A Finstar des classes, les associations identifiees jusqu'a present ne forment 
qu'une ebauche de structure statique. II convient a present de les valider, les 
preciser, en eliminer, et en ajouter. La encore, il s'agit d'une activite iterative, 
qui sera completee grace a 1' identification des attributs. 

N'oub lions pas qu'en analyse, les associations representent des relations 
conceptuelles entre les classes. On peut egalement dire qu'elles impliquent 
des responsabilites en termes de navigation. La navigation dans un modele 
statique represente la capacite a obtenir des informations en parcourant les 
associations entre les classes. Lexemple de la figure 7-2 indique que Ton peut 
demander a une Commande quelles sont les DescriptionColis qui lui sont 
rattachees et reciproquement a toute DescriptionColis a quelle Commande 
elle est rattachee. On peut done considerer les associations comme porteuses 
d'une partie fondamentale de la structure statique des classes, en ce sens qu'il 
est de la nature d'une Commande d'etre reliee a des DescriptionColis. 
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En revanche, ces responsabilites ne prejugent pas de la structure des classes en 
conception. C'est en effet durant l'etape de conception detaillee (voir 
chapitre 11), qu'on effectue les choix d' implementation du modele structurel, 
avec des objectifs d' optimisation et de modularite. 

Voici deux principes generaux qui permettent d'eliminer les associations 
incorrectes ou inutiles : 

associations non structurelles : elles expriment des relations dynamiques, 
c'est-a-dire des liens instantanes entre objets. Les liens structurels se 
caracterisent par une certaine duree et une certaine stabilite ; 

associations redondantes : elles peuvent etre retrouvees par navigation 
grace aux associations existantes. 



ETUDE DE CAS : ASSOCIATIONS A ELIMINER 

II n'incombe pas a une Commande de savoir quel Repartiteur est en train de la selectionner pour 
I'affecter a une Mission. II s'agit d'une relation purement dynamique entre un acteur Repartiteur et 
un objet Commande. L'association ne doit done pas figurer dans le modele statique, mais etre 
exprimee par une construction dynamique, comme I'envoi de messages. 



Repartiteur 




Commande 



Figure 7-3 : Association erronee entre Commande et Repartiteur 

Un EnCoursDeCmd concerne une Commande, une Commande concerne un Client. II serait inu- 
tile d'ajouter une association entre EnCoursDeCmd et Client pour preciser qu'un EnCoursDeCmd 
concerne un et un seul Client. En effet, implicitement, un parcours enchainant plusieurs associa- 
tions combine les multiplicity successives, en multipliant respectivement entre elles les bornes 
minimales et les bornes maximales. En voici un exemple : 

• de EnCoursDeCmd a Clienten passant par Commande, la multiplicity s'obtient par : (1..1) x 
(1..1) = 1..1 ; 

• dans I'autre sens, de Client a EnCoursDeCmd en passant par Commande, la multiplicity 
s'obtient par :(0..*)x(0..1) = 0..*, 

L'association concerne est done totalement redondante avec les deux autres associations et 
peut etre supprimee sans consequence. 
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conceme 




Figure 7-4 : Association redondante entre EnCoursDeCmd et Client 



INFLUENCES DES MULTIPLICITES SUR LES ASSOCIATIONS 

La multiplicite exprimee sur les associations doit etre vraie a tous les moments 
du cycle de vie des instances. Elle induit done des contraintes sur le processus 
d'instanciation des classes. Dans l'exemple de la figure 7-4, on ne peut pas 
instancier d' EnCoursDeCmd sans lui assigner une instance de Commande. En 
revanche, pour instancier une Commande, il n'est evi detriment pas obligatoire 
de lui associer des le depart un EnCoursDeCmd... La difference entre « 0..1 » 
et « 1 » est par consequent plus forte qu'il n'y parait. 

De meme, la semantique des classes associees et de F association elle-meme peut 
subtilement influencer les multiplicites. Une illustration en est donnee par les 
trois exemples suivants, tous corrects 1 , mais ayant des significations differentes. 



Man 


1 marie in ci I 


hpouse 





Homme 



0.1 



f 



CpOH 



0.1 



Kemmc 





a ele marie avec 




Homme 


hemrne 


0..* 


0..* 



Figure 7-5 : Exemples de multiplicites differentes pour des associations voisines 

Un Mari est forcement marie a une et une seule Epouse, dans le contexte de la 
loi francaise actuelle. En revanche, si les concepts plus generaux $ Homme et 
de Femme nous interessent independamment des liens du mariage, 1' association 
devient optionnelle ; Mari et Epouse deviennent alors des roles. Vous remar- 
querez au passage combien la difference entre classe et role est tenue, dans la 
mesure oil elle depend fortement du contexte du probleme. Si enfin, on veut 
conserver l'historique des liens de mariage, la multiplicite devient non bornee. 

1 .Attention, precisons que ces diagrammes sont corrects dans le contexte de la loi francaise en ce 
debut d'annee 2007 ! lis excluent en effet la polygamie ainsi que le mariage homosexuel. . . 
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Affiner les associations consiste egalement a utiliser deux notions comple- 
mentaires fournies par UML : l'agregation et la composition. 

Une association entre deux classes represente par defaut une relation structu- 
relle symetrique entre entites de meme importance. Mais UML fournit deux 
notions qui permettent d'affiner la definition conceptuelle d'une association. II 
s'agit de l'agregation et de la composition qui ajoutent a 1' association le sens 
d'une relation d'elements a ensemble. 

Si l'une des classes joue le role d' ensemble compose d' instances de F autre 
classe, utilisez l'agregation. Une agregation n'est plus semantiquement syme- 
trique, puisqu'elle privilegie l'une des deux classes en relevant au rang de 
conteneur. L'agregation garde cependant les proprietes d'une association et 
n'influe ni sur 1' expression des multiplicites, ni sur la navigabilite, ni sur le 
cycle de vie des instances reliees. Par consequent, il est possible de partager 
l'agregation : une partie peut appartenir simultanement a plusieurs agregats. 

La composition est en revanche une variante d' agregation qui influe sur la 
structure des instances qu'elle relie. Avec une composition, nous introduisons 
ainsi les deux caracteristiques suivantes : 

la composition n'est pas partageable : un objet ne peut appartenir qu'a un 

seul composite a la fois ; 

le cycle de vie des parties est fortement lie a celui du composite : la des- 
truction du composite entraine en particulier la destruction de ses parties. 



ETUDE DE CAS : AGREGATION ET COMPOSITION 



ZoneTerminale 

(from Plan de Transport) 



Zo neRed istri but ion 

(from Plan de Transport) 




,1 1 



Agence 



Vehicule 




Agregation 
Composition 



Chauffeur 




Quai 



OperateurQuai 



Receptionniste 



Figure 7-6 : Exemples d'agregation et de composition autour de la classe Agence 
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Dans cet exemple, toutes les associations ont la semantique de I'agregation. Mais verifient-elles 
en plus les criteres de la composition ? Le premier critere (non partageable) est bien verifie par 
toutes les agregations sauf celle entre ZoneRedistribution et Agence. En revanche, seule I'agre- 
gation entre Agence et Quai correspond au critere d'imbrication du cycle de vie entre composite 
et composants. Par exemple, la suppression d'une Agence n'entraine pas celle de ses vehicules 
et chauffeurs, qui vont etre reaffectes a une autre agence. 

Si I'on reprend I'exemple de la figure 7-2, on peut egalement distinguer une composition et une 
agregation, en fonction du critere qui consiste a lier les cycles de vie des parties a leur ensem- 
ble : la suppression d'une commande implique celle de ses descriptions de colis. 



Figure 7-7 : Exemples d'agregation et de composition dans la categorie Commandes 



Affiner les associations, c'est aussi identifier leurs regies de gestion. UML 
propose un certain nombre de proprietes standard applicables aux associa- 
tions : 

on peut specifier que les objets a une extremite de l'association doivent 
etre ordonnes avec la propriete { ordered } ; 

on peut egalement preciser qu'un lien ne peut plus etre modifie ni detruit 
avec la propriete {frozen}. Dans le meme esprit, la propriete 
{addOnly} signifie que de nouveaux liens peuvent etre ajoutes depuis 
un objet de F autre cote de l'association, mais non supprimes 1 . 

II est a noter que la propriete {ordered} n'induit pas la facon dont les 
objets vont etre ordonnes : numero, ordre alphabetique, etc. II s'agit en 
general d'un choix de conception. 




1. Meme si les contraintes predefinies {frozen} et {addOnly} semblent avoir disparu du standard 
UML 2, nous continuerons a les utiliser pour leur valeur ajoutee. 
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ETUDE DE CAS : PROPRIETES DES ASSOCIATIONS DES CATEGORIES 



IncidentMission 



{ordered} 




Proprietes 



donne lieu a 



0. 1 



FeuilleDeRoute 



d&cnt 



{ordered} 



EvenementMission 



Mission 



1.' 



{ordered} 



Etape 



{ordered} 



Commande 

(from Commandes) 



est planifiee pour 



0 1 



Figure 7-8 : Associations ordonnees dans la categohe Missions 

Les associations entre IncidentMission, EvenementMission et Mission ne sont pas seulement 
ordonnees. En effet, les liens ne pouvant plus etre modifies ni detruits du cote Mission, ils s'ajou- 
tent obligatoirement de I'autre cote. 



EvenementMission 



{ordered, addOnly} {ordered, addOnly} 



4 

{frozen} 



Proprietes 

1 



1..* 



{frozen} 



Figure 7-9 : Autres proprietes des associations de la categorie Missions 

Dans la categorie Comptabilite, une reflexion plus poussee sur les multiplicites, les proprietes et 
la navigabilite permet d'eliminer une association redondante et supprime de la sorte la 
dependance entre les categories Comptabilite et Clients. 
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{frozen} 



1 



Facture 



1 



{frozen} 
donne lieu a 

ordered, addOnly} 



Association 
redondante 



0 1 



{frozen} 



Relance 



Commande 
(from Commandes) 



Figure 7-10: Proprietes des associations de la categorie Comptabilite 



Ajouter les attributs 

Un attribut est une propriete nominee d'une classe qui decrit un domaine de 
valeurs possibles partage par tous les objets de la classe. A tout instant, 
chaque objet d'une classe porte une valeur specifique pour chaque attribut de 
sa classe. Dans un modele d' analyse, vous conserverez uniquement comme 
attributs les proprietes simples des classes que le systeme doit memoriser et 
utiliser. 

Exemples SIVEx : 

un Vehicule a un n° d'immatriculation et un kilometrage ; 
un Chauffeur et un Client ont un nom ; 

une Commande a une reference, un cout estime et un type de service ; 
un Colis a un poids. 

DIFFERENCE ENTRE CLASSE ET ATTRIBUT 

En analyse, un concept est une entite utilisee par l'expert du domaine dans le 
cadre de son metier ou de 1' application. Tout concept doit etre modelise par 
une classe car il est implicitement porteur de proprietes, assume des respon- 
sabilites fonctionnelles dans le systeme et parcourt eventuellement des etats 
differents. 

L' attribut n'est qu'une des proprietes d'une classe se caracterisant par une 
quantite mesurable, comme le poids du Colis, ou la possibilite d'etre valorise 
par une ou plusieurs donnees, par exemple le nom d'un Client. 



© 
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Notez encore qu'un attribut peut etre valorise par une structure de donnees 
ou bien qu'il peut etre multiple au sein d'une classe. Contrairement a ce que 
nous rencontrons souvent dans les projets, ces caracteristiques ne transfor- 
ment pas pour autant un attribut en classe. Dans l'exemple ci-dessous, l'ana- 
lyste comprend qu'un Point n'est pas manipule par l'utilisateur et que Ton 
peut valoriser un Point par la donnee de deux coordonnees dans son modele. 
II transforme done la classe Point en attribut multiple dans les differentes 
classes geometriques. Remarquez comment le diagramme s'en trouve allege. 



Segment 



PolyLigne 




Rectangle 



Segment 



pointDebut 
pomtFin 



Rectangle 



pointJ4] 



PotyUgne 



poinljl -|^_ 



Multiplicit* 



Figure 7-11 : Attribut ou classe ' 



Nous allons illustrer la difference entre attribut et classe sur F etude de cas, 
ainsi que trois erreurs frequentes de modelisation liees au concept d' attribut. 



ETUDE DE CAS : ATTRIBUTS ERRONES OU REDONDANTS 

Le Compte d'un Client n'est pas un simple nombre, e'est un concept a part entiere comportant 
lui-meme plusieurs attributs ; il peut etre bloque ou debloque, ce qui implique des etats et des 
responsabilites. 



Client 



leroComo 








Compte 


Client 


possGde 


numero 
solde 


nom 


♦ 

1 0.1 









Figure 7-12: Exemple d'attribut abusif 

Un autre defaut frequent consiste a decrire correctement I'association entre les deux classes, 
mais a ajouter tout de meme un attribut redondant dans I'une des classes. Par exemple, la classe 
Commande n'a pas besoin d'un attribut nomClient, puisque chaque Commande concerne un 
Client qui a deja un nom. 
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Attribut 



Commande 
reference 

■ nomC lio nt ■< 

coutEstime 
dateProbaEnlevemen 




dateProbaLivraison 



Figure 7-13: Attribut redondant avec une association 

Le cas suivant est un peu plus complexe, car la correspondance n'est pas directe. Cependant, la 
encore, I'attribut est inutile en analyse, car il peut etre deduit de la navigation de I'association. Le 
nombre de colis d'une Commande s'obtient simplement en comptant le nombre d'objets Des- 
criptionColis lies a I'objet Commande correspondant. 



Attribut 
redondant 





Commande 


I 1 


DescriptionColis 


reference 

nambroCslic ' 


descriptif 
matiere 
poidsEstime 
volumeEstime 




coutEstime 

dateProbaEnlevemen! 

dateProbaLivraison 


1 1..* 





Figure 7-14 : Attribut inutile car implicite d'apres I'association 

Le cas contraire peut egalement arriver : une des classes candidates s'avere representor un 
« type simple », et non un concept du domaine. C'est le cas dans la categorie Reseau, ou la 
classe Commune est superflue. En effet, elle ne sert qu'a stacker une structure de donnees 
represented la position d'un Site, Comme dans I'exemple de la figure 7-1 1 , on peut simplifier le 
modele en la transformant en attribut. Notez aussi la multiplicity et la navigabilite de I'associa- 
tion : le fait que Commune ne soit pas tenue de connaitre ses Sites est un argument qui joue en 
faveur de sa suppression. 




Figure 7-15: Remplacement d'une classe candidate parun attribut 
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DENOMINATION DES ASSOCIATIONS PAR LES ROLES 



La difference subtile entre les concepts d' attribut et de classe se retrouve 
egalement dans la notion de role d'une extremite d' association. 
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Revenons sur les deux facons possibles de nommer les associations. La pre- 
miere consiste a utiliser un groupe verbal, afin que F association puisse etre lue 
comme une phrase. C'est ainsi que procedaient les methodes traditionnelles de 
modelisation de donnees. Cette methode presente un inconvenient : le sens de 
lecture du verbe n'est pas forcement le sens naturel (de gauche a droite ou de 
haut en bas) apres plusieurs remaniements de diagramme. Cependant, en ana- 
lyse, c'est souvent la technique la plus simple a mettre en ceuvre. 

La deuxieme consiste a nommer le role que joue chacune des classes dans 
son association avec F autre. Ce role represente une sorte d'attribut complexe 
de la classe distante, il est done decrit par un substantif. L inconvenient de la 
methode precedente est ainsi resolu, puisque les noms de roles restent bien 
« accroches » a leur extremite d' association, me me si on les deplace graphi- 
quement. De plus, le substantif a de grandes chances d'etre utilise lors de la 
generation de code (voir le chapitre 1 1 sur la conception detaillee). 



Commande 



enlevement r 



reference 
coutEstime 
/ poidsEstime 
typeService 
modePaiemen' 




Figure 7-16 : Exemples de roles a" association 

II est a noter que les noms de roles sont obligatoires pour les associations qui 
bouclent sur une classe, comme celle de la classe Site sur la figure prece- 
dente 

Toutefois, il faut rester pragmatique : ne nommez les associations que si le 
nom apporte une information significative pour le lecteur. Inutile de preciser 
est relie a, est associe a ou de recopier le nom de la classe comme nom de 
role ! Certaines associations sont evidentes ; par ailleurs n'oubliez pas que 
Fagregation et la composition signifient deja quelque chose par elles-memes. 



DISTINGUEZ LES ATTRIBUTS DERIVES ! 

Un attribut derive est un attribut interessant pour Fanalyste, mais redondant, 
car sa valeur peut etre deduite d'autres informations disponibles pour la 
classe concernee. UML permet a la fois de le citer en tant qu'attribut, d'indi- 
quer au lecteur du modele son caractere redondant grace au « / » et enfin 
d'exprimer la contrainte associee. 



c 

Conseil 



146 



UML en action 



ETUDE DE CAS : ATTRIBUTS DERIVES 

Le cas le plus simple est celui d'un attribut derive d'un autre attribut de la meme classe. Par 
exemple, I'age d'un Chauffeur est derive de sa date de naissance. 



Chauffeur 



Naissance 



Contrainte 

\ 

{age = dateCourante - dateNaissance) 
Attribut derive 



Figure 7-17 : Attribut derive et contrainte 

En analyse, un attribut derive indique seulement une contrainte entre deux proprietes, un inva- 
riant, comme le montre I'exemple precedent. II ne precise pas encore ce qui doit etre calcule par 
rapport a ce qui doit etre stocke : ce sera un choix de conception. 

Un attribut derive peut aussi etre deduit de fagon plus complexe. Par exemple, le poids estime 
d'une Commande est egal a la somme des poids estimes de ses descriptions de colis. 



Attribut 
derive 



Commande 



reference 

cflutEslime^^^ 
/ poidsEstime 

teProbaErnevement 
dateProbaLivraison 




DescnptionColis 



descriptif 
matiere 
poidsEstime 
volumeEstime 



Contrainte 



{Commande" poidsEsfime = 
Somme (DescriptionColis poidsEstime)} 



Figure 7-18: Autre exemple d'attribut derive 



DISTTNSUEZ LES ATTRIBUTS DE CLASSE ! 

Par defaut, un attribut a une portee d' instance : chaque objet de la classe pos- 
sede sa propre valeur pour la propriete. Dans certains cas plus rares, 1' attri- 
but peut avoir une portee de classe : il existe alors une seule valeur commune 
de la propriete pour toutes les instances de la classe. On parle dans ce cas 
d'attribut de classe 1 , et on le souligne pour le distinguer des attributs d' ins- 
tance. 



l.La plupart des outils de modelisation proposent plutot une case a cocher « static », d'apres le 
mot-cle correspondant en Java, C++ ou C#. 
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ETUDE DE CAS : ATTRIBUT DE CLASSE 



date 
heui 



TransmissionComptable 



heure. 

C heurePlan<fiee = 22Fi> 



/ ecarT 



transmet 



0 1 



Facture 

(from Comptabilite) 



{ecart = heure - heurePlanifiee) 



Attribut de classe 



Figure 7-19 : Attribut de classe 

Les factures sont transmises en fin de journee au module CO de SAP : la classe Transmission- 
Comptable comporte deux attributs principaux : une date et une heure de transmission effective. 
On souhaite suivre les ecarts de transmission reelle par rapport a I'heure planifiee, soit 22 h tous 
les soirs. II suffit pour cela d'ajouter un attribut de classe heurePlanifiee, dont la valeur est identi- 
que pour tous les objets de la classe, et un attribut derive ecarf. 



Ne pas faire 



N'UTILISEZ PAS LA NOTATION COMPLETE DE L'ATTRIBUT EN ANALYSE ! 

Dans les diagrammes precedents, nous avons simplement indique le nom des 
attributs. C'est generalement suffisant pour le lecteur d'un modele d'analyse. 
II sait parfaitement ce qu'est une date, un poidsEstime, ou un coutEstime. 

La syntaxe complete d'un attribut en UML est evidemment plus complexe : 

[visibilite] nom [multiplicity ] [: type] [= val_init] 
[ {propriete } ] 

Les declarations optionnelles (entre « [ ] ») sont utiles en conception ; certai- 
nes sont meme necessaires. En revanche, en analyse, nous vous conseillons 
de ne les employer qu'avec parcimonie, le risque etant de faire premature- 
ment des choix de conception injustifies. En analyse, il faut rarement antici- 
per le type, la valeur initiale, ou la visibilite. Les seules declarations 
interessantes sont les suivantes : 

la multiplicite permet de simplifier certains diagrammes, en exprimant de 
fatjon condensee des structures de donnees, comme nous 1' avons vu a la 
figure 7-11; 

la valeur initiale est surtout utile pour les attributs de classe (comme dans 
l'exemple de la TransmissionComptable : heurePlanifiee = 22h) ; 
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Ne pos faire 



la propriete {frozen } permet d'indiquer un attribut dont la valeur ne 
peut plus changer une fois que l'objet a ete cree. 

La propriete permet d'indiquer un attribut dont la valeur ne peut pas etre 
modifiee par les objets clients. 



TransmissionComptable 




date/(frozen}> 
heurWfrozen)'. 
heurePlanlfiee = 22h 



/ ecart 



Proprietes 

. Valeur initials 



nessageErreur [0.."] 

— *Z 



Multiplicity 



\_ Attribut derive 

Figure 7-20 : Utilisation avancee de la syntaxe de I'attribut en analyse 

Nous venons de voir comment affiner les classes, affiner les associations et 
ajouter les attributs. II arrive que Ton ait besoin d'effectuer les trois activites a 
la fois : ajouter une classe pour decrire des attributs portes par une association. 

En effet, une association entre deux classes peut elle-meme comporter des 
attributs. L'exemple type est celui de la relation « employeur/employe » entre 
Societe et Personne. Ou placer les proprietes de salaire, anciennete, etc., si les 
multiplicites sont « 0..* » des deux cotes de l'association ? II faut valoriser ces 
attributs pour chaque couple d'instances (Societe-Personne), et pas simple- 
ment pour un objet. 

La solution en UML consiste a modeliser cette association comme une classe 
Emploi qui contient les proprietes de l'association. II existe alors une instance 
d'Emploi pour chaque lien entre objets des deux classes. La classe Emploi est 
appelee classe d 'association ; il s'agit d'un element de modelisation UML qui 
est a la fois une classe et une association. Elle peut done a son tour etablir des 
relations avec d'autres classes, comme Emploi avec ConventionCollective . 



Personne 




Figure 7-21 : Exemple de classe d'association 
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La figure suivante presente une instanciation possible du diagramme prece- 
dent, dans lequel les objets El et E2 portent des valeurs differentes pour 
certains attributs. Nous ne les avons pas indiques pour des raisons evidentes 
de confidentialite :-). 




Instance de 
classe 
d' association 



Figure 7-22 : Exemples d'objets dissociation 



Dans la categorie Reseau, chaque Parcours decrit en realite une relation entre deux Sites (il en 
va de meme pour les Connexions entre Agences). Le modele se trouve ameliore si Ton trans- 
forme Parcours et Connexion en classes d'associations. 
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Figure 7-23 : Exemple de classe d'association dans SIVEx 

Notez que I'existence d'un objet Parcours est obligatoirement subordonnee au lien entre deux 
objets Site. Cette relation de dominance entre Site et Parcours est plus clairement exprimee par 
la deuxieme solution : celle ou Parcours devient une classe d'association. 
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Une association ne peut comprendre des proprietes qu'en se transformant en 
classe d' association. En consequence, le nom de la classe d'association est 
egalement celui de 1' association. Vous pouvez neanmoins nommer egalement 
les roles portes par les extremites de cette association, comme a la figure 7-23. 

II peut arriver que vous vouliez decrire les memes proprietes pour plusieurs 
associations. Dans ce cas, vous ne pouvez pas reutiliser une classe d'associa- 
tion en l'attachant a d'autres associations, puisqu'elle est 1' association elle- 
meme. Une solution peut consister a definir une super-classe (generalement 
abstraite) dont heriteront les differentes classes d'association, comme illustre 
a la figure ci-apres. 



att1 
att2 
att3 



AB 



CD 



G 



Definition 



Figure 7-24 : Super-classe d'association 

Parfois, un ou plusieurs attributs initialement affectes a une classe ne servent 
qu'a preciser la designation d'objets par le biais d'une association. 

QU'EST-CE QU'UN QUALIFICATIF ? 

Un qualificatif 1 est un attribut d'association dont les valeurs partitionnent la 
liste des objets relies par le biais d'une association. En d'autres termes, la 
connaissance d'un objet et d'une valeur de qualificatif permet de retrouver 
un ou plusieurs objets lies a 1' autre bout de 1" association concernee. 

Le qualificatif affine done Faeces a une instance par navigation sur une asso- 
ciation. II ne s' applique evidemment qu'a une multiplicite superieure a « 1 » 
puisqu'on ne peut partitionner une liste composee d'un seul element. 

1 .Ou « qualifieur » ? II s'agit en eft'et d'une traduction du terme anglais qualifier . . . 



La definition du qualificatif n'est pas aisee a saisir sans exemple, nous en 
developpons ci-apres differentes utilisations. 

Reprenons par exemple la relation « employe-employeur » de la figure 7-21. 
Ou placer 1' attribut matricule ? A premiere vue, il s'agit d'une propriete de la 
classe Personne. Mais en fait, une personne possede un matricule pour chacun 
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de ses employeurs. II s'agit done plutot d'un attribut de Fassociation, que nous 
pouvons placer dans la classe Emploi. Poussons 1' analyse encore un peu plus 
loin : a quoi sert 1' attribut matricule sinon a referencer un employe au sein de 
son employeur ? II s'agit d'un identifiant relatif, dont la valeur permet 
d'acceder a une instance particuliere de Personne, pour une Societe donnee. 
C'est exactement la notion de qualificatif en UML. II se represente graphique- 
ment comme indique a la figure ci-apres, qui recapitule les etapes de la trans- 
formation d'un attribut en attribut d' association, puis en qualificatif, avec la 
reduction de multiplicite qui s'ensuit. 



qualificatif 



Sccieie 



nom 
activite 



matricule 

"TF 



employeur 



3. La 
multiplicite 
est reduite 



employe 



\ 



►° 1 X 



2. L ' attribut 
d' association 

devient 
qualificatif 



Emploi 



descnptionPoste 

salaire 

anciennete 

motr i ot il o^ 



Personne 



nom 
prenom 



matricu l e 



1. L' attribut 
devient attribut 
d' association 



Figure 7-25 : Exemple de qualificatif remplagant un attribut 

Un objet Societe dote d'une valeur particuliere du qualificatif matricule a 
acces a un objet Personne au plus, car la multiplicite a ete reduite a « 0..1 ». II 
peut y avoir des numeros de matricule inutilises, d'ou la limite inferieure a 0. 



ETUDE DE CAS : QUALIFICATIFS 

Une Agence contient des Quais et chaque Quai y est reference par un numero. Ce numero 
represente un identifiant relatif a une Agence particuliere, et non un identifiant absolu du Quai. 
Dans un sens, numero n'est pas seulement un attribut de I'association, puisqu'il permet d'identi- 
fier de fagon unique un Quai par rapport a une Agence. 



Agence 



Agence 



Quai 



1 



numero w- 




Quai 



^ Qualificatif 

Figure 7-26 : Exemple de qualificatif dans la categorie Ressources 
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Notez bien la modification de la multiplicity de I'autre cote du qualificatif. Pour une instance 
d'Agence et une valeur de numero, il existe au plus un Quai. Autrement dit, dans une agence 
donnee, deux quais ne peuvent porter le meme numero. 

Attention cependant, car meme si c'est le cas le plus frequent, un qualificatif ne reduit pas syste- 
matiquement la multiplicity de « 0..* » a « 1 » (ou « 0..1 »). Supposons que chaque Agence 
possede plusieurs pares de vehicules. Si I'on utilise le numero de pare comme qualificatif, la mul- 
tiplicity du cote de la classe Vehicule reste « 0..* ». 




— Qualificatif 


Vehicule 


nolmmatnculation 
kilometrage 
charge 
estLibre 


1 0 * 





Figure 7-27 : Exemple de qualificatif ne reduisant pas la multiplicite 



Ajouter les operations (optionnel) 

Une operation represente un service, un traitement qui peut etre demande a 
n'importe quel objet de la classe. Une operation est F abstraction de ce que vous 
pouvez realiser sur un objet, et elle est partagee par tous les objets de la classe. 

Souvent, invoquer une operation sur un objet modifie son etat ou les valeurs de 
certains attributs, ou encore l'existence de certains liens avec d'autres objets. 

En analyse, il est possible d' identifier certaines operations par analyse textuelle 
du cahier des charges et des fiches de description des cas d'utilisation. II faut 
chercher des verbes d'action, comme « envoyer », « valider », les verbes d'etat 
comme « appartient a » ou « concerne », se traduisant plutot par des associations. 



Les commandes sont saisies par un reception niste a partir des informations^ 
fournies par les clients Lors de la prise de commande, le receptionniste doit 
disposer du cout estime de la prestation et des dates probables 
d'enlevement et de livraison Ces informations doivent pouvoir etre editees 
et envoyees directement par Fax ou coumer electronique au client 



Commande 



coutEstime 

dateProbaEnlevement 
dateProbaLivraison 




- 

1 



Client 

((rom Clients) 



Operations 



Figure 7-28 : Exemples d'operations identifies par analyse textuelle 
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Soyez toutefois vigilants dans la mesure ou toutes les operations identifiees de 
cette facon ne sont pas pertinentes. Certains verbes ne traduisent pas des 
operations metier, mais plutot des traitements de 1'IHM comme les operations 
saisir et editer de l'exemple precedent, qui ne seront pas conservees. D'autres 
verbes representent des operations implicites en analyse, qui ne seront done 
pas indiquees sur le diagramme de classes. 

Au prochain chapitre, nous verrons que la meilleure facon d'identifier les 
operations consiste a etudier la dynamique de 1' application : les interactions 
entre les objets et les etats des classes en fournissent la matiere premiere. 



NE REPERTORIEZ PAS LES OPERATIONS IMPLICITES EN ANALYSE ! 

Ne pas faire Pour ne pas surcharger les diagrammes de classes, il est inutile de recenser 
certaines operations implicites pour toutes les classes, comme : 

la creation et la destruction d' instances : constructeur et destructeur en 
programmation objet ; 

la manipulation des attributs, a savoir lecture et modification : accesseurs 
en programmation objet ; 

la creation et la destruction de liens, implicites d'apres les associations, 
avec leurs multiplicites et leurs proprietes eventuelles ; 
les parcours et les recherches sur les associations. 

Notez que cette recommandation s' applique souvent tout aussi bien en con- 
ception, puisque la plupart des outils UML du marche sont capables d'ajou- 
ter automatiquement les operations citees precedemment. 

De meme, les operations « non metier » liees en particulier a 1'IHM ou au stoc- 
kage physique seront ajoutees ulterieurement. II n'est done pas etonnant qu'une 
classe d' analyse ait rarement plus de quatre ou cinq operations. Toutes les autres 
operations, implicites ou non metier, viendront s'ajouter en conception 1 . 



Ne pas faire 



N'UTILISEZ PAS LA NOTATION COMPLETE 

Comme pour les attributs, le nom des operations est suffisant pour le lecteur 
d'un modele d' analyse. II comprend ce que signifient envoy er, bloquer, vali- 
der. Au mieux, il se referera au modele dynamique pour saisir le contexte 
dans lequel l'operation est effectuee (voir chapitre 8). 



1. Depuis plusieurs annees, la tendance consiste a reporter ['identification des operations dans 
les classes a l'etape de conception. De nombreux auteurs recommandent soit de ne lister en ana- 
lyse que des « responsabilites » (et pas de figer l'interface de la classe) soit carrement de ne pas du 
tout s'occuper des operations ! Voila la raison pour laquelle nous avons indique en debut de chapi- 
tre que l'ajout des operations dans le modele d'analyse est optionnel. 
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©La syntaxe complete d'une operation en UML est evidemment plus com- 
plexe : 

Ne pos faire 

[visibilite] nom [ (liste_param) ] [: type_retour] [{pro- 
priety } ] 

Mais il est clair qu'en analyse, le nom de F operation et un commentaire textuel 
suffisent. Toutes les autres informations ne seront utiles qu'en conception. 

Comme pour les attributs, une operation a une portee d' instance par defaut : 
elle s' applique a un objet de la classe. Certaines operations ont une portee de 
classe, on parle alors d' operation de classe. Les deux exemples les plus 
courants d'operations de classe sont : 

les operations qui permettent de creer de nouvelles instances ; 

les operations qui manipulent les attributs de classe. 

Or, d'apres ce que nous avons dit precedemment, ces types d'operations sont 
implicites en analyse. On peut done en conclure que les operations de classe 
sont tres rarement utiles en phase d' analyse, en tout cas nettement moins que 
les attributs de classe. 



ETUDE DE CAS : OPERATIONS DES CLASSES 
DE LA CATEGORIE CLIENTS 



Comple 



bloquer() 
debtoquer( 



Utilisateur 

(from Exploitation Inlrxmaltqoei 



{frozen) 



I 



Client 



nom 
numTel 
numFax 
email 



{frozen} 1 



Profi Commercial 



description 
taux Remise 



Site 

(from r«wmi 



LocaiisationClienI 



Figure 7-29 : Operations des classes de la categorie Clients 

Notez les deux seules operations vraiment « metier » de la classe Compte. Toutes les autres 
seraient des operations implicites de manipulation d'attributs. 

Ces operations font penser a des changements d'etat. Le modelisateur doit done considerer 
['opportunity de realiser un diagramme d'etats pour la classe Compte (voir chapitre suivant). 
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Optimiser avec la generalisation 

A ce stade, il s'agit de decouvrir les classes possedant des caracteristiques 
communes : attributs, associations, operations. Les proprietes communes 
seront rassemblees dans une super-classe, et les proprietes specifiques reste- 
ront dans les sous-classes. 



ETUDE DE CAS : GENERALISATION DE LA CLASSE 
EVENEMENT MISSION 

Reprenons I'exemple du suivi de mission (figure 7-8). Si nous ajoutons les attributs et les opera- 
tions et que nous extrayons la classe SuiviMission de la classe Mission existante (pour bien 
separer les responsabilites), nous obtenons le diagramme suivant : 



IncidentMission 



date 
type 

descriptif 
retardEstime 



transmettre 

archiver 

acquitter 



EvenementMission 



type 



transmettre 
archiver 



{ordered. addOnly} 



{ordered, addOnly} 



{frozen} 



SuiviMission 



1..* 



{frozen} 



Figure 7-30 : IncidentMission et EvenementMission 

II est clair que nous pouvons simplifier ce schema en considerant IncidentMission comme une 
sous-classe d' EvenementMission. En effet, toutes les proprietes d' EvenementMission se retrou- 
vent dans IncidentMission, et semantiquement un IncidentMission est bien une sorte dEvene- 
mentMission. On obtient alors : 







date 
type 


■j • conceme ^ 




SuiviMission 


transmettre 
archiver 


{ordered. addOnly} {frozen} 





IncidentMission 
typclncidcnt 
descriptif 
retardEstime 



Generalisation 



Figure 7-31 : EvenementMission comme generalisation d'lncidentMission 
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On peut meme affiner plus avant en distinguant deux types d'incidents : les incidents de trajet 
(panne du vehicule, etc.) et les incidents d'etape (client absent, livraison refusee, etc.). 



EvenementMission 


1..* concerne 1 


SurviMission 


date 
type 


/ dateDepart 
/ dateArrivee 


{ordered, addOnly) {frozen} 


transmettreO 
archrverO 






Classe 
abstraite 



InadentMission 



descnptif 



acquitter() 



IncidentTrajet 



typelncidentTrajet 
retard Estime 



IncidentEtape 




Etape 


typetncidentEtape 


{frozen} 









Figure 7-32 : Arbre de generalisation d'EvenementMission 

Dans le diagramme precedent, vous remarquez que la classe IncidentMission est en italique. En 
UML, cela signifie que cette classe est abstraite, c'est-a-dire qu'on ne peut pas I'instancier direc- 
tement. Autrement dit, pour instancier la super-classe abstraite IncidentMission, il taut obligatoi- 
rement instancier une de ses sous-classes, qui sont pour leur part concretes. 

Une super-classe n'est pas forcement abstraite. Ainsi, la classe EvenementMission ne I'est pas, 
car il peut en exister des instances directes. Sa sous-classe IncidentMission est en revanche 
abstraite, ce qui montre que la super-classe d'une classe abstraite peut etre concrete I 

Nous avons dit qu'lncidentMission peut etre considered comme une sous-classe d'Evenement- 
Mission, puisque toutes les proprietes d'EvenementMission valent egalement pour IncidentMis- 
sion, et qu'elle a des proprietes specifiques supplementaires. 

Une autre fagon de I'exprimer consiste a utiliser le principe de substitution de Liskov. Partout ou 
nous parlons d'EvenementMission (la super-classe), nous devons pouvoir lui substituer n'importe 
laquelle de ses sous-classes, sans que cela cause le moindre probleme. Si nous ecrivons la 
phrase : « Un EvenementMission concerne une et une seule Mission, il est date et peut etre 
archive», nous pouvons remplacer EvenementMission par IncidentMission, IncidentTrajet, ou 
IncidentEtape, et la phrase doit rester vraie. 



Ne pas taire 



N'ABUSEZ PAS DE LA GENERALISATION/SPECIALISATION ! 

On s'apercoit parfois, apres avoir ajoute les attributs et les operations, que 
certaines sous-classes ont ete distinguees a tort. En effet, elles ont les memes 
proprietes et les memes comportements et peuvent etre facilement fusion- 
nee s. 
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ETUDE DE CAS : AFFINEMENT DE GENERALISATIONS 



Prenons les differentes sous-classes d'Utilisateur, que nous retrouvons dans plusieurs catego- 
ries. Si Chauffeur et Cfenf ont bien des attributs et des associations propres, on peut se passer 
de Receptionniste et OperateurQuai. 

C'est le cas egalement pour les sous-classes MissionEnlevement et MissionLivraison, qui ne pre- 
sented aucune difference fondamentale. II est done souhaitable de les fusionner en une seule 
classe MissionDeTournee, en ajoutant simplement un attribut nature pour pouvoir les distinguer. 
Nous conservons en revanche I'autre sous-classe MissionTraction, car elle possede une associa- 
tion supplemental (avec Agence), ainsi que des regies de gestion differentes. 



Mission 
reference 
dateDepartPrevue 
dateArriveePrevue 
commentaire 



Agence 
Res* 

A 




Traction 



destination 



reference 
dateDepartPrevue 
dateArriveePrevue 



responsable 



Agence 

[from Ressources 



MissionDeTournee 




MissionTraction 


nature 











Figure 7-33 : Simplification de I'arbre de generalisation de Mission 

Notez que la classe Mission est maintenant consideree comme une classe abstraite. 

Pour la categorie Ressources, nous avons separe le modele statique sur deux diagrammes de 
classes : 

• un diagramme general sur les agences, 

• puis le detail concernant les vehicules et les chauffeurs. 

Nous n'avons pas encore envisage le fait qu'une ressource d'une agence peut etre provisoire- 
ment mise a disposition d'une autre agence. II en resulte des associations supplementaires par- 
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tant d'Agence, et arrivant a Vehicule et Chauffeur. Pour factoriser toutes ces associations 
identiques, nous avons introduit une super-classe abstraite Ressource. 

Notez egalement la classe d'association MiseADisposition. Les dates de mise a disposition des 
ressources d'une agence a une autre sont typiquement valorisees pour chaque couple (Agence, 
Ressource). 




Figure 7-34 : Ressources : diagramme general de I'agence 

La figure suivante presente le detail concernant les chauffeurs et les vehicules. On peut remar- 
quer I'heritage multiple de la classe Chauffeur. En effet, tout chauffeur est un Utilisateur, mais 
aussi une Ressource. Des lors que le principe de substitution est respecte, il n'y a pas de raison 
d'interdire la generalisation multiple en analyse. 



General isation 
multiple 



Utilisateur 
(from Exploitation Infomiatiquel 




Chauffeur 



nom 

dateNaissance 
permis 



Vehicule 



nolmmatnculation 
kilometrage 
charge 
estlibre 



Figure 7-35 : Generalisation multiple de la classe Chauffeur 
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Encore un petit effort ! 



Le modele statique doit rendre compte au final de toutes les regies structu- 
relles. II sera certes complete par le modele dynamique, mais doit etre 
exhaustif pour tout ce qui concerne les relations statiques et le contenu des 
classes. 

II faut egalement s' assurer de son homogeneite, de sa coherence, et de sa 
modularite. A cet effet, il est necessaire de verifier si les responsabilites attri- 
butes aux classes sont coherentes, homogenes et pas trop nombreuses. II 
arrive frequemment que Ton puisse ameliorer encore le modele en introdui- 
sant des classes supplementaires appelees metaclasses, comme nous allons 
l'illustrer avec F etude de cas. 



ETUDE DE CAS : AJOUT DE LA METACLASSE TYPE VEHICULE 



Reprenons la liste des responsabilites de la classe Vehicule (cf. chapitre 4). Nous pouvons la 
completer par la gestion du numero d'immatriculation et du kilometrage, ainsi que la notion de 
qualification des chauffeurs suivant le type de vehicule. La traduction de chacune de ces res- 
ponsabilites, sous forme d'attributs ou d'associations, est detaillee dans le schema suivant : 



Si I'on regarde plus attentivement, on s'apergoit que les responsabilites R2 et R4 ne dependent 
pas de chaque instance de Vehicule. En effet, les capacities d'un vehicule dependent exclusive- 
ment de son type. De meme, un chauffeur est qualifie pour un type de vehicule, et non pour un 
vehicule particulier. La bonne solution de modelisation consiste a isoler cette notion de type de 




Figure 7-36 : Traduction des responsabilites de la classe Vehicule 
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celle de vehicule, afin de mieux repartir les responsabilites. A cet effet, nous allons creer une 
nouvelle classe, appelee TypeVehicule, et modifier la repartition des attributs et associations de 
la fagon suivante : 



Agence 



Responsabilitfes : C\ 

1 - gerer son kilometrage 
et son N° d'immatriculation 

2 - connaltre son Agence 
de rattachement ; 

3 -- savoir s'il est affecte a 
s'il est I 



Vehicule 



nolmmatriculation 

kilometrage 

estLibre 



est de type 



estatectei 
0.1 



Mission 



Responsabilites : C 

1 - connaitre ses capacites 
(poids max en charge 
encombrement, etc ); 

2 - determiner si un 
chauffeur est qualifie ou non 



TypeVehicule 



nom 

chargeMax 
volume 
hauteur 
largeur 



1..* 



es( qu j/ifle pour 



Chauffeur 



Figure 7-37 : Separation des responsabilites en ajoutant TypeVehicule 



Vous pouvez noter que cette maniere de proceder est reutilisable quel que soit 
le contexte 1 . On identifie une classe XX qui possede de nombreuses responsa- 
bilites. Certaines ne sont pas propres a chaque instance. On ajoute alors la 
classe TypeXX ou ModeleXX et on repartit les attributs et associations sur les 
deux classes. On termine en reliant XX et TypeXX par une association « * - 1 », 
souvent unidirectionnelle vers TypeXX. La classe TypeXX est quaMee de 
metaclasse, car elle contient des informations qui decrivent la classe XX. 



XX 


Metaclasse 

> 


«metadasse» 

TypeXX 


att1 
att2 


att3 
att4 


1 







Figure 7-38 : Schema generique reutilisable (pattern d'analyse). 



1. On peut parler dans ce cas de pattern d'analyse (analysis pattern). 
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On nomme classiquement delegation la technique consistant pour un objet a 
deleguer une partie de ses responsabilites a un autre objet lie. Dernier avan- 
tage de cette solution : elle permet de lier de nombreuses instances de XX a la 
meme instance de TypeXX, au lieu de repeter les valeurs communes des attri- 
buts att3 et att4. 



AJOUTEZ DES CONTRAINTES ! 

Nous avons precedemment evoque des proprietes predefinies en UML con- 
cernant les attributs et les associations. II est parfois utile d'exprimer des 
contraintes plus sophistiquees entre plusieurs elements de modelisation. 
C'est le cas pour les attributs derives ; cela peut egalement concenter les 
associations. On peut ainsi indiquer des contraintes d'inclusion ou d'exclu- 
sion entre associations, des contraintes de navigation ou des contraintes de 
derivation. 

Attention cependant : on peut, si on abuse des contraintes, etre tente de com- 
bler des lacunes de modelisation par ce biais. 



ETUDE DE CAS : AJOUT DE CONTRAINTES SUR LES ATTRIBUTS 
ET LES ASSOCIATIONS 



Voici un exemple de contrainte d'inclusion entre associations : 



principale 




L'agence principale 
est unc des agenecs 
conlcnucs dans la 
/.oncRcdisiribuuon 



Figure 7-39 : Exemple de contrainte d'inclusion entre associations 

Nous avons deja signale un certain nombre de contraintes sur les attributs, telles que celles qui 
expriment la derivation des attributs derives, comme indique aux figures 7-17, 7-18, et 7-19. 

Le schema suivant traduit un autre exemple de contrainte entre attributs. 
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Vehicule 




TypeVehicule 



nolmmatriculation 
kilometrage 
charge , 
estLibre ' 



{self.charge <= self.typeVehicule.chargeMax} 



nom 

chargeMax 
volume 
hauteur 
largeur 

vitesseMaxVide 
vitesseMaxCharge 



Figure 7-40 : Exemple de contrainte entre atthbuts 

Remarquez la notation pointee qui est utilisee dans la contrainte de la figure precedents. En fait, 
elle fait partie d'une syntaxe plus etendue appelee OCL et proposee par UML. Le langage OCL 
(Object Constraint Language) fait en effet partie prenante d'UML et permet d'exprimer des con- 
traintes sous forme d'expressions booleennes qui doivent etre verifiees par le modele. Mais son 
utilisation n'est absolument pas imposee, et suivant I'objectif du modele, vous pouvez exprimer 
vos contraintes en texte libre, ou plus formellement en OCL. 

OCL est un langage a expressions, sans effet de bord sur le systeme modelise. Sans entrer dans 
les details, I'exemple suivant montre I'utilisation du langage OCL. La contrainte que nous voulons 
exprimer formellement est la suivante : un colis est dans I'etat nominal s'il n'a pas donne lieu a la 
moindre anomalie. 



Colis 


concerne 

1 


AnomalieColis 


poids 
etat 


date 
type 


{frozen} {frozen, addOnly} 







{(self.etat = nominal) implies (self.anomalieColis ->size = 0)} 
Contrainte en OCL . — ' 

Figure 7-41 : Exemple de contrainte exprimee en OCL 

OCL definit plusieurs types de collections d'objets, ainsi que de nombreuses operations de mani- 
pulation de ces collections. Set est un ensemble au sens mathematique. Lexpression 
self.anomalieColis retourne I'ensemble des objets AnomalieColis lies a I'objet colis con- 
cerne. L'operation predefinie size permet de tester si I'ensemble est vide. 



Phases de realisation du 
modele statique d'analyse 

Le developpement du modele statique constitue la deuxieme etape de la phase 
d'analyse. Les diagrammes de classes preliminaires obtenus lors du 
decoupage en categories sont detailles, completes et optimises. 
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II faut d'abord valider les classes et les associations candidates. Ce travail 
d'affinement est iteratif : il ne faut pas hesiter a modifier, ajouter ou meme 
supprimer des classes et des associations, en se fondant sur la definition de 
leurs responsabilites. Sur les associations retenues, on precise les multipli- 
cites, les proprietes, les contraintes, et Ton distingue les agregations et les 
compositions. On ajoute ensuite les attributs, en distinguant les attributs 
derives et les attributs de classe. Cela conduit frequemment a identifier des 
classes d' association, et des qualificatifs. Une premiere recherche d' opera- 
tions peut alors etre effectuee ; elle sera completee lors de F analyse dyna- 
mique. On optimise ensuite les diagrammes de classes en introduisant des 
super-classes par generalisation, tout en respectant le principe de substitution. 

La demarche mise en ceuvre dans ce chapitre est synthetisee par la figure 
suivante : 




Figure 7-42 : Demarche d 'elaboration du modele statique 



Chapitre Developpement du 
6 modele dynamique 



Objectifs du chapitre 

Ce chapitre va nous permettre d'illustrer l'utilisation des concepts dynami- 
ques d'UML et des diagrammes associes en phase d' analyse. 

Nous verrons tout d'abord comment decrire des scenarios mettant en jeu un 
ensemble d'objets echangeant des messages. Ces interactions peuvent etre 
decrites au moyen de deux types de diagrammes : le diagramme de sequence, 
qui met l'accent sur la chronologie des messages et le diagramme de commu- 
nication (appele collaboration en UML 1 .x), qui souligne les relations structu- 
relles des objets en interaction. 

Nous detaillerons ensuite la facon de decrire le cycle de vie d'un objet d'une 
classe particuliere, au fil de ses interactions et de son evolution propre. Le 
diagramme d'etats permet en effet une description precise et exhaustive des 
etats d'un objet et des transitions causees par l'arrivee d'evenements, y 
compris les reponses de l'objet. Nous verrons done comment utiliser efficace- 
ment les nombreux concepts des diagrammes d'etats, ou statecharts. 



Quand intervient le 
developpement du modele 
dynamique ? 

Le developpement du modele dynamique constitue la troisieme activite de 
l'etape d'analyse. Elle se situe sur la branche gauche du cycle en Y. II s'agit 
d'une activite iterative, fortement couplee avec 1' activite de modelisation 
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statique, decrite au chapitre precedent. Pour les besoins du livre, nous avons 
ete obliges de les presenter de facon sequentielle, mais dans la realite elles 
sont effectuees quasiment en parallele. Le developpement du modele dyna- 
mique precede Fetape de conception preliminaire. 



Branche Branche 
fonctionnette technique 




Figure 8-1 : Situation du developpement du modele dynamique dans 2TUP 



Elements mis en jeu 

Scenarios, diagrammes de sequence et de communication, 
Message, evenement, signal, appel d' operation, 
Classes d' analyse de Jacobson, 
Etat et activite, 
Transition et condition, 

Transitions propres et internes, activites d' entree et de sortie, 
Etats composites, sous-etats sequentiels, sous-etats paralleles. 

Identifier les scenarios 

Nous avons vu au chapitre 4 qu'un cas d'utilisation decrit un ensemble de 
scenarios. Lors de l'etape de determination des besoins fonctionnels, un 
scenario represente une sequence d' interactions entre le systeme et ses 
acteurs. Le systeme est alors considere comme une boite noire. Maintenant 
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que nous avons developpe le modele statique d' analyse, nous allons remplacer 
le systeme par une collaboration d'objets dans chaque scenario. 



£ 1 Syst 1 ^ 

Act) L- ■ — 1 Act2 




tM 


Le niveau < 



Les objets instances 
des classes d' analyse 
remplacent le systeme 



vision boite noire 
du systeme 



Ne pas faire 




Figure 8-2 : Changement de niveau des scenarios 

Un scenario decrit une execution particuliere d'un cas d' utilisation du debut a 
la fin. II correspond a une selection d' enchainements du cas d' utilisation. 

On peut distinguer plusieurs types de scenarios : 

nominaux : ils realisent les postconditions du cas d' utilisation, d'une facon 
naturelle et frequente ; 

alternatifs : ils remplissent les postconditions du cas d' utilisation, mais en 
empruntant des voies detournees ou rares ; 

aux limites : ils realisent les postconditions du cas d' utilisation, mais 
modifient le systeme de telle sorte que la prochaine execution du cas d' uti- 
lisation provoquera une erreur ; 

d'erreur : ne realisent pas les postconditions du cas d' utilisation. 

NE CHERCHEZ PAS L'EXHAUSTIVITE DES SCENARIOS ! 

Un scenario correspond a l'execution d'un ou de plusieurs enchainements, 
joignant le debut du cas d' utilisation a une fin normale ou non. II est clair 
que la combinatoire des enchainements fait exploser le nombre de scenarios 
potentiels ! Nous ne pourrons done pas tous les decrire. II faudra faire des 
choix, essayer de trouver le meilleur rapport « qualite/prix », e'est-a-dire 
F ensemble minimal de scenarios permettant de couvrir toutes les actions/ 
reactions du systeme. Cela revient a definir une famille de scenarios qui 
empruntent au moins une fois toutes les branches d' execution du cas d' utili- 
sation. Conformement a ce que nous vous avons explique au chapitre 4, le 
diagramme d'activite qui restitue ces chemins fournit un outil tres efficace 
pour trouver les scenarios suffisants. 
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Figure 8-3 : Representation des variantes d'un cas d 'utilisation 

Nous pouvons nous fixer comme objectif de couvrir toutes les executions 
importantes et realistes du cas d' utilisation, et de faire intervenir chaque 
enchainement au moins dans un scenario. 

II s'agit d'un probleme analogue a celui du testeur qui doit definir des jeux 
de test necessaires et suffisants, tout en sachant que l'exhaustivite n'est pas 
possible. 



ETUDE DE CAS : SCENARIOS DE « PLANIFICATION DES MISSIONS » 

Parmi tous les scenarios possibles pour le cas d'utilisation « Planification des Missions » (PM), 
nous avons choisi les suivants : 

O scenarios nominaux : 

• PM_N1 : creation d'une mission de traction validee, 

• PM_N2 : annulation d'une mission d'enlevement en attente ; 

O scenarios alternatifs : 

• PM_A1 : modification d'une mission de livraison par ajout d'une commande, 

• PM_A2 : creation d'une mission d'enlevement avec estimation incomplete ; 

O scenarios aux limites : 

• PM_L1 : affectation du dernier vehicule et du dernier chauffeur de I'agence ; 

O scenarios d'exception : 

• PMJE1 : non-validation de la creation de mission pour cause de depassement de tonnage, 

• PM_E2 : non-validation de la creation de mission pour cause de chauffeur non qualifie, 

• PMJE3 : non-validation de la creation de mission pour cause de tonnage de reserve entame, 

• PM_E4 : essai d'annulation d'une mission moins d'une heure avant son depart. 
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Formaliser les scenarios 



© 

Etude 



En analyse, un scenario represente un ensemble ordonne de messages 
echanges par des objets. On parle ici d'objet au sens large : instance de classe 
d' analyse ou instance d'acteur. 

Le concept de message a ete introduit au chapitre 3 pour le modele de 
contexte dynamique. Nous allons y revenir en detail maintenant. 

DIFFERENCE ENTRE MESSAGE, SIGNAL ET APPEL D'OPERATTON 

Un message represente la specification d'une communication unidirection- 
nelle entre objets qui transporte de 1' information avec F intention de declen- 
cher une reaction chez le recepteur. II peut comprendre des parametres qui 
transferent des valeurs de l'emetteur au recepteur. On distingue deux grandes 
categories de messages : 

le signal : une communication asynchrone explicite et nommee entre 
deux objets, 

I'appel : F invocation synchrone d'une operation, avec un mecanisme 
pour rendre ensuite la main a l'emetteur. 

Au niveau logique, l'envoi d'un signal et I'appel d'une operation sont simi- 
laires. lis impliquent tous deux une communication qui transmet de F informa- 
tion par valeur d'un emetteur a un recepteur pour le faire reagir. La difference 
fondamentale entre les deux reside dans F asynchronisme du signal, qui est ega- 
lement unidirectionnel. L'appel d' operation, au contraire, est une communica- 
tion synchrone pendant laquelle le flot de controle passe temporairement de 
l'appelant a l'appele. L' appelant perd le flot de controle pendant F execution de 
F operation et le recupere a la fin de celle-ci. On peut considerer l'appel d' opera- 
tion comme un signal avec un parametre de retour implicite vers l'appelant. En 
analyse, nous vous conseillons d'utiliser le concept de signal, qui a une 
semantique plus simple et plus generate que l'appel d'operation. 1 

1 .La notation graphique des messages synchrones et asynchrones a evolue avec les versions suc- 
cessives d'UML, semant le trouble chez les utilisateurs et les editeurs d'outils... Nous employons 
dans nos diagrammes la notation UML 2, a savoir fleche pleine pour l'appel synchrone et fleche 
evidee pour le message asynchrone. Comme indique, nous utiliserons principalement les messa- 
ges asynchrones dans ce chapitre. 



Les echanges de messages entre objets peuvent etre represented en UML dans 
deux sortes de diagrammes complementaires : 

le diagramme de sequence, qui met F accent sur la chronologie des messages ; 

le diagramme de communication (appele collaboration en UML 1.x), qui 

souligne les relations structurelles entre les participants qui echangent les 

messages. 
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DIAGRAMME DE SEQUENCE OU DE COMMUNICATION ? 

Le diagramme de sequence et le diagramme de communication contiennent 
en fait le meme type d' information. 

II convient alors de se poser la question suivante : quelle est la meilleure 
representation visuelle pour ce que je souhaite montrer au lecteur ? 

Si je veux mettre l'accent sur l'aspect chronologique des communica- 
tions, j'ai interet a choisir le diagramme de sequence. 
Si je veux faire ressortir les relations structurelles des participants qui 
interagissent, il est preferable que j'opte pour le diagramme de communi- 
cation. 

D'une maniere generale, la plupart des auteurs considerent qu'en analyse, le 
diagramme de sequence est plus apte a representer un scenario dans le 
contexte d'un cas d' utilisation, et qu'en conception, le diagramme de commu- 
nication se prete mieux a la representation des iterations et des branchements 
complexes, ainsi que des Hots de controle paralleles 1 . 

On peut egalement l'exprimer de la facon suivante : 

Quand il y a peu de participants mais beaucoup d'echanges entre eux, pre- 
ferer le diagramme de sequence. 

Quand il y a beaucoup de participants qui interagissent, adopter le dia- 
gramme de communication. 

Neanmoins, le choix est personnel et depend aussi notablement des capacites 
de Foutil de modelisation utilise. De nombreux outils du marche proposent 
d'ailleurs de generer automatiquement une forme a partir de F autre, laissant 
completement libre le modelisateur. 

Pour illustrer les differences et la complementarite des deux types de 
diagrammes d' interaction, nous allons detailler plusieurs scenarios du cas 
d' utilisation « Planification des missions ». 



ETUDE DE CAS : DIAGRAMMES DE SEQUENCE 

ET DE COMMUNICATION DU CAS « PLANIFICATION DES MISSIONS » 

Prenons le scenario PMJM1 : « Creation d'une mission de traction validee ». Nous voulons forma- 
liser la sequence de messages suivante : 

1. Cependant, les ajouts d'UML 2.0 au diagramme de sequence (en particulier les cadres d'inte- 
ractions avec operateur : loop, alt, opt, etc.) font maintenant nettement pencher la balance vers 
celui-ci. 
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• le repartiteur donne un nom d'identification et etablit la nature de la mission qu'il veut creer. 
Comme c'est une mission de traction, il doit indiquer une agence principale de destination ; 

• le repartiteur affecte les commandes a la nouvelle mission. Le systeme evalue au fur et a 
mesure des affectations le tonnage estime de la mission ; 

• le repartiteur affecte un vehicule et un chauffeur a la mission, en fonction du tonnage evalue ; 

• le repartiteur valide la mission ; il doit alors preciser I'heure de depart prevue. Le systeme 
produit pour sa part une feuille de route. 

Pour decrire ce scenario, nous allons faire intervenir les lignes de vie suivantes : 

• un acteur Repartiteur, 

• une mission creee au cours du scenario : nouvelleMTMissionTraction, 

• un element d'une collection 1 representant chacune des instances de Commande qui vont 
etre affectees a la nouvelle mission, 

• un objet Vehicule et un objet Chauffeur, 

• une feuille de route creee en fin de scenario. 

Le diagramme de sequence formalisant le scenario PMJ\I1 est presente a la figure 8-4. 



cmdAffectees[i] : 




vehiculeAffecte 




chauffeur Affecte : 


Commande 




: Vehicule 




Chauffeur 



loop 



En fonction du 
tonnage total 
evalue 



create 
(nouvelleMT) 



nouvelleMT : 
MissionTraction 



setDestination(agenceXX) . | 



[Pour chaque command* selectionnee] 
affecter( nouvelleMT ) 



tonnageEstime 



affecterfnouvelleMT ) 



affecter(nouvelleMT ) 



valider(heureDepart) 



:FeuilleDeRoute 



Figure 8-4 : Diagramme de sequence du scenario PM_N1 

Outre les notations de base que nous supposons connues, nous avons utilise sur ce premier dia- 
gramme des notations avancees telles que : 

• la creation d'une instance nouvelleMT (ou FeuilleDeRoute) au cours du scenario, figuree par 
le rectangle aligne en face de la fleche pointillee du message de creation, et non en haut du 
diagramme, comme d'habitude ; 

• Iteration, indiquee par le cadre avec I'operateur loop ; 

• les notes sont egalement tres utiles pour preciser visuellement le contexte d'utilisation d'un 
message, ou d'un groupe de messages. Notre recommandation consiste a les regrouper 



1 . Notez la syntaxe avec index pour exprimer le fait que la ligne de vie represente un element 
d'une collection de commandes : cmdAffectees[i]. 
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systematiquement dans la marge gauche du diagramme. 

Autre maniere de formaliser le scenario : elaborer un diagramme de communication. La encore, 
nous supposons les notations de base connues. 



6: arfecter{nouvelleMT ) 

^* chauffeurAffecte 

: Chauffeur 




List<Commande> 



Figure 8-5 : Diagramme de communication du scenario PM_N1 

Nous avons ete amenes a introduire trois notations avancees : 

• Iteration, indiquee par I'asterisque, permet d'indiquer graphiquement que le message 
*af f ecter (nouvelleMT) est envoye a un ensemble d'objets, et non a un seul ; 

• la contrainte predefinie {new} precise que I'objet est cree pendant I'execution de I'interaction 
englobante et continue d'exister a la fin. Cette notation a la meme signification que le rectan- 
gle en face de la fleche du message de creation sur le diagramme de sequence ; 

• la numerotation decimale des messages permet d'indiquer I'imbrication des appels : au lieu 
de numeroter en sequence (1, 2, 3...), on voit sur I'exemple que 7: valider(heureDepart) est 
suivi de 7. 1: create, pour indiquer que la creation est declenchee par la validation. 

Prenons maintenant le scenario PMJM2 : « Annulation d'une mission d'enlevement en attente ». 
Nous voulons formaliser la sequence de messages suivante : 

• le repartiteur donne un nom d'identification et etablit la nature de la mission qu'il veut creer, 
en I'occurrence enlevement ; 

• le repartiteur affecte une premiere commande a la mission. Le systeme evalue au fur et a 
mesure des affectations le tonnage estime de la mission. II propose egalement I'ordre des 
etapes a suivre ; 

• le repartiteur decide d'annuler la mission. Le systeme doit alors defaire les actions prece- 
dentes. 

Le diagramme de sequence formalisant le scenario PM_N2 est schematise a la figure 8-6. 
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: Repartiteur 



Traitement 
Interne 




Figure 8-6 : Diagramme de sequence du scenario PM_N2 

Remarquez I'utilisation de notations complementaires sur ce diagramme de sequence : 

• la fleche qui pointe vers un objet, comme estimerPoids sur la Commande, permet de repre- 
senter un traitement interne a I'objet. Meme si tel n'est pas le but du diagramme d'interac- 
tions, cette indication explique plus finement le scenario, et sert surtout a preparer un 
eventuel diagramme d'etats de la classe concernee ; 

• la croix noire terminant une ligne de vie indique que I'objet est detruit pendant le scenario. 
Elle permet de distinguer visuellement les objets qui continuent a vivre a la fin du scenario de 
ceux qui ne lui survivent pas ; 

• le message destroy est le pendant de create, alors que terminate est une convention 
pour indiquer I'autodestruction. 

La figure 8-7 represente le diagramme de communication correspondant. La encore, la notation 
decimale permet d'indiquer I'imbrication des messages. La contrainte predefinie (transient) 
specifie que I'objet est cree puis detruit au cours du scenario. 
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Trait ement 
interi 



1 : create(nouvelleME) 
2: setNature(enlevement) 
6: annuler( } 



transient} 




3.2: poidsEstime 


N 


f \ 






cmdAffectee : 
Commande 


> 



3: affecter(nouvel leME ) 
: Repartiteur 

Figure 8-7 : Diagramme de communication du scenario PM_N2 



Nous avons evoque precedemment le probleme incontournable de la prolifera- 
tion des scenarios. Pour ne pas multiplier les diagrammes, nous vous 
conseillons de : 

regrouper plusieurs scenarios sur un me me diagramme s'ils constituent 
des variantes tres proches. C'est notamment le cas pour les scenarios 
d' exception qui se greffent generalement sur les diagrammes de sequence 
representant les cas nominaux. Utilisez des notes textuelles en marge des 
diagrammes pour indiquer les branchements, ou les nouvelles notations 
UML 2 avec les cadres et les operateurs alt ou opt. Neanmoins, si les 
variantes sont trop differentes, ne les regroupez pas car cela nuirait forte- 
ment a la lisibilite ; 

modeliser un enchainement plutot qu'un scenario complet si cet enchai- 
nement est complexe et commun a plusieurs scenarios. La encore, 
UML 2.0 a ajoute la notion de reference a une autre interaction, represen- 
tee par un cadre rectangulaire avec le mot-cle ref. Notez que l'idee de 
branchements entre scenarios est tout a fait comparable aux relations 
<<include>> et «extend» entre cas d' utilisations (voir chapi- 
tre 4). II est d'ailleurs courant que la factorisation d'enchainements con- 
duise a affiner les cas d' utilisation en extrayant des cas inclus ou 
d' extension. 

II est clair que les techniques precedentes s'appliquent parfaitement au 
diagramme de sequence, mais peuvent egalement s' adapter au diagramme de 
communication. On peut par exemple utiliser un message ou une note pour 
faire reference au renvoi a un autre diagramme de communication. 
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ETUDE DE CAS : EXCEPTIONS DANS LE SCENARIO PM_N1 

Nous allons completer le diagramme de sequence du scenario PMJM1 en indiquant deux excep- 
tions possibles : le depassement de tonnage et le chauffeur non qualifie. 

Remarquez I'utilisation de notes pour reperer I'occurrence des exceptions au cours du scenario, 
ainsi que la condition de poursuite de I'enchatnement nominal. Le declenchement des excep- 
tions est exprime au moyen de conditions simples. Vous noterez que le diagramme ainsi 
complete reste parfaitement lisible, tout en contenant plus d'informations. La lisibilite est bien le 
critere principal pour ce type de diagramme en analyse. Nous vous conseillons d'adopter la 
regie pragmatique suivante : un diagramme de sequence ou de communication doit tenir sur une 
page A4, tout en restant lisible. 



: Repartiteur 



cmdA11ectees[i] 
Gommande 



vehiculeAffecte 


chau ff eurAtfecte : 


: Vehicule 
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Figure 8-8 : Diagramme de sequence combinant les scenarios PM_N1, PM_E1 et PM_E2 



Nous allons d'abord realiser un diagramme de sequence « classique » du 
scenario nominal de creation d'une nouvelle commande. 
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CLASSES D'ANALYSE DE JACOBSON 

De nombreux auteurs (par exemple Conallen [Conallen 00] et Rosenberg 
[Rosenberg 01]), suivant les preconisations de Jacobson reprises dans le 
RUR differencient des F analyse trois types de classes : 

Les classes qui permettent les interactions entre 1' application et ses utili- 
sateurs sont qualifiees de boundary. II y a au moins une boundary pour 
chaque paire (acteur - cas d'utilisation). 

Celles qui contiennent la cinematique de 1' application sont appelees con- 
trol. Elles font la transition entre les boundary et les classes metier. Les 
control ne donneront pas forcement lieu a de vrais objets de conception, 
mais assurent que nous n'oublions pas de fonctionnalites ou de compor- 
tements requis par les cas d'utilisation. 

Celles qui representent les objets metier sont qualifiees A' entity. Ce sont 
tres souvent des entites persistantes, c'est-a-dire qui vont survivre a 
l'execution d'un cas d'utilisation particulier. 

II existe des regies precises sur les interactions possibles entre instances de 
ces trois types de classes d' analyse : 

Les acteurs ne peuvent interagir (envoyer des messages) qu'avec les 
boundary. 

Les boundary peuvent interagir avec les control ou exceptionnellement 
avec d'autres boundary. 

Les control peuvent interagir avec les boundary, les entity, ou d'autres 
control. 

Les entity ne peuvent interagir qu'entre elles. 

Le changement de niveau d' abstraction par rapport au diagramme de 
sequence vu au chapitre 4 peut ainsi se representer comme sur la figure sui- 
vante, mettant en ceuvre les notations graphiques proposees par Jacobson 
pour ses classes d' analyse. 
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Nous allons etudier 1' utilisation de ces types de classes d' analyse sur une 
autre partie de 1' etude de cas. 
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ETUDE DE CAS : TRAITER UNE COMMANDS 
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Figure 8-9 : Diagramme de sequence du scenario nominal de creation d'une commande 

Notez que ce diagramme (ainsi que les trois suivants) a ete cree avec Foutil 
Together de Borland selon le standard UML 1.5. Cela explique par exemple 
les bandes blanches d' activation le long des lignes de vie, la notation des 
instances avec le souligne (supprimee par UML 2.0), ainsi que la notation de 
l'iteration : *[tous] //create (...). 

Une version completee montrant les classes d' analyse de Jacobson (a savoir 
une boundary et un control) est donnee ci-apres. Nous avons garde la notation 
rectangulaire de F entity par commodite et utilise la fleche de retour en poin- 
tilles manipulee par l'outil Together. 
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figure 8-^0 : Diagramme de sequence a la Jacobson du scenario 
nominal de creation d'une commande 

Les echanges entre la boundary et le control n'ont pas toujours une grande 
valeur ajoutee. En consequence, on peut egalement adopter une solution inter- 
mediaire : garder uniquement un objet control mais ne pas montrer d'objet 
boundary. C'est ce que nous avons realise sur le diagramme suivant, qui 
reprend le scenario nominal de creation de mission. Comparez-le attentive- 
ment a celui de la figure 8-4 qui ne permettait pas bien de representer le fait 
que le systeme fournit au repartiteur la liste des commandes a traiter et des 
ressources disponibles. 
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Figure 8-11 : Diagramme de sequence (avec control) du scenario nominal de creation de mission 



Le diagramme de communication correspondant, avec le control central caracteristique, est 
donne ci-apres : 
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Figure 8-12 : Diagramme de communication (avec control) du scenario nominal de creation de mission 
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Construire les diagrammes d'etats 

Maintenant que les scenarios ont ete formalises, la connaissance de Fensemble 
des interactions entre objets permet de se representer les regies de gestion dyna- 
mique du systeme. II faut cependant se focaliser sur les classes aux comporte- 
ments les plus riches de maniere a developper precisement certaines de ces regies 
dynamiques. On recourt a cet effet au concept de machine a etats finis, qui 
consiste a s'interesser au cycle de vie d'un objet generique d'une classe 
particuliere au fil de ses interactions avec le reste du monde, dans tous les cas 
possibles. Cette vue locale d'un objet, decrivant comment il reagit a des evene- 
ments en fonction de son etat courant et passe dans un nouvel etat, est representee 
graphiquement sous forme d'un diagramme d'etats. 

0*. QU'EST-CE QU'UN ETAT ? 

Un etat represente une situation durant la vie d'un objet pendant laquelle : 

Definition 

• il satisfait une certaine condition ; 
il execute une certaine activite ; 
ou bien il attend un certain evenement. 

Un objet passe par une succession d'etats durant son existence. Un etat a une 
duree finie, variable selon la vie de l'objet, en particulier en fonction des 
evenements qui lui arrivent. 

La notion d' evenement merite egalement d'etre abordee de maniere plus 
detaillee. 



LES TYPES D'EVENEMENTS EN UML 

En UML, un evenement specifie qu'il s'est passe quelque chose de significa- 
tif, localise dans le temps et dans l'espace. Dans le contexte des machines a 
etats finis, il represente 1' occurrence d'un stimulus qui peut declencher une 
transition entre etats. 

UML propose de distinguer plusieurs sortes d' evenements : 

la reception d'un signal envoye par un autre objet, ou par un acteur. Le 
concept d' exception, present dans les langages C++ et Java, est un bon 
exemple de signal. L envoi d'un signal est en general asynchrone ; 
Yappel d'une operation {call event) sur l'objet recepteur. L'evenement 
d'appel est en general synchrone ; 

le passage du temps (time event), qui se modelise en utilisant le mot-cle 
after suivi d'une expression representant une duree, decomptee a 
partir de l'entree dans l'etat courant ; 
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un changement dans la satisfaction d'une condition (change event). On 
utilise alors le mot-cle when, suivi d'une expression booleenne. L'evene- 
ment de changement se produit lorsque la condition passe a vrai. 

La terminaison d'une activite durable (do-activity) a l'interieur d'un etat. 
L'objet change alors d'etat de lui-meme. 

Revenons maintenant aux machines a etats. Une machine a etats specifie les 
sequences d' etats qu'un objet peut parcourir durant sa vie en reponse aux 
evenements qui lui adviennent, ainsi que les reactions correspondantes. Toutes 
les classes du modele statique ne requierent pas necessairement une machine a 
etats, representee par un diagramme d'etats. II s'agit done de trouver celles qui 
ont un comportement dynamique complexe necessitant une description 
poussee. Cela correspond a l'un des deux cas suivants : 

les objets de la classe peuvent-ils reagir differemment a l'occurrence du 
meme evenement ? Chaque type de reaction caracterise un etat particulier ; 

la classe doit-elle organiser certaines operations dans un ordre precis ? 
Dans ce cas, des etats sequentiels permettent de preciser la chronologie 
forcee des evenements d' activation. 



PAS DE DIAGRAMME D'ETATS A MOINS DE TROIS ETATS ! 

Ne perdez pas de temps a dessiner des diagrammes d'etats contenant seule- 
ment deux etats (de type « on/off »...), et encore moins un seul ! Dans ce 
cas, la dynamique de la classe est simple et peut etre apprehendee directe- 
ment. 

Si vous suivez ce conseil, vous vous apercevrez que seules 10 a 20% des 
classes ont besoin d'une description detaillee sous forme de diagramme 
d'etats. 

Comment trouver les etats d'une classe ? Pour faire un parallele, on peut dire 
qu'il est aussi difficile de trouver les bons etats dans le modele dynamique que 
les bonnes classes dans le modele statique ! 

II n'y a done pas de recette miracle, cependant trois demarches comple- 
mentaires peuvent etre mises en ceuvre : 

la recherche intuitive repose sur F expertise metier. Certains etats fonda- 
mentaux font partie du vocabulaire des experts du domaine et sont identi- 
fiables a priori (par exemple : en vol et au sol pour un avion) ; 

l'etude des attributs et des associations de la classe peut donner des indica- 
tions precieuses : cherchez des valeurs seuils d' attributs qui modifient la 
dynamique (mineur ou majeur pour une personne), ou des comportements 
qui sont induits par l'existence ou l'absence de certains liens ; 
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une demarche systematique peut egalement etre utilisee : classe par classe, 
cherchez le diagramme d'interaction le plus representatif du comporte- 
ment des instances de cette classe, associez un etat a chaque intervalle 
entre evenements emis ou recus par une instance et placez les transitions. 
Reproduisez ensuite cette demarche avec tous les scenarios faisant interve- 
nir des instances de la classe, afin d'ajouter de nouvelles transitions ou de 
nouveaux etats. La difficulte principale consiste a trouver ensuite les bou- 
cles dans le diagramme, afin de ne pas multiplier les etats. 

Comme toujours, nous vous conseillons un melange astucieux des trois 
demarches. 

Ensuite, pour elaborer le diagramme d'etats, nous preconisons une approche 
incrementale fondee sur les etapes suivantes : 

representez d'abord la sequence d'etats decrivant le comportement nomi- 
nal d'un objet, de sa naissance a sa mort, avec les transitions associees ; 

ajoutez progressivement les transitions correspondant aux comportements 
alternatifs ; 

puis integrez, de la meme facon, celles concernant les comportements 
d'erreur ; 

completez en indiquant les effets sur les transitions et les activites dans les 
etats ; 

structurez en sous-etats, si le diagramme est devenu trop complexe. 



ETUDE DE CAS : DIAGRAMME D'ETATS DE LA CLASSE MISSION 

Nous allons illustrer cette approche incrementale de construction du diagramme d'etats 
en prenant I'exemple concret de la classe Mission. Pour cela, nous nous baserons sur les 
diagrammes d'interactions deja realises, ainsi que sur I'etude des scenarios des cas « Pla- 
nification des Missions » et >< Suivi des Missions ». 

Si Ton considere les diagrammes d'interactions du scenario nominal PM_N1, on peut deja 
identifier deux etats importants : 

• En attente: de la creation d'une instance de mission a sa validation, cet etat inclut 
toutes les operations d'affectation de commandes et de ressources ; 

• Validee: dans le cas nominal, les affectations se sont bien passees et le repartiteur 
valide la mission, qui attend alors son depart effectif. 

Pour terminer la sequence d'etats representant le comportement nominal d'une Mission, 
nous allons ajouter un etat En cours, et un etat Terminee. Nous obtenons alors un pre- 
mier squelette de diagramme d'etats, presente sur la figure 8-13. 
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create! nom, nature ) 



En attente 



valider( dateDepartPrevue ) 



Validee 



depart 



Terminee 



En cours 



Figure 8-13 : Transitions nominates du diagramme d'etats de la classe Mission 

Ajoutons maintenant les transitions correspondent aux comportements alternatifs : 

• la possibility de modifier une mission en attente, ou deja validee ; 

• la possibility d'annuler une mission validee, mais pas encore partie. Nous sommes 
ainsi amenes a introduire un etat final. 

modifier 



create) nom, nature ) 



En attente 



modifier 



Validee 



annuler 



valider( dateDepartPrevue ) 



annuler 



depart 



Terminee 



En cours 



Figure 8-14 :Ajout des transitions alternatives surle diagramme d'etats de la classe Mission 



Notez egalement I'utilisation de la transition propre, qui pointe vers I'etat En attente. 

En fait, on ne peut plus ni modifier ni annuler une mission moins d'une heure avant le 
depart prevu. Une premiere solution consiste a ajouter une condition de garde sur les 
transitions correspondantes, comme illustre a la figure 8-15. 
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modifier 



createf nom, nature ) 



Condition 




modifier 

dateCourante < dateDepart Prevue -1h] 



Validee 



valider( dateDepartPrevue ) 

annuler 

[ dateCourante < dateDepartprevue -1h] 



Figure 8-15: Exemples de conditions surle diagramme d'etats de la classe Mission 



Pour eviter de dupliquer la condition [ dateCourante < dateDepartPrevue -1h ], il est egalement possi- 
ble de la remplacer par un etat intermediaire entre Validee et En cours, que nous appellerons Non 
modifiable. Mais quel evenement declencherait la transition entre Validee et Non modifiable? II ne 
s'agit pas d'un evenement declenche par la reception d'un message, mais d'un changement interne a 
I'objet lui-meme. La notion de change event evoquee precedemment repond a ce besoin. La transition 
est done declenchee par I'occurrence de when {dateCourante < dateDepartPrevue -1h). 

Si nous voulons exprimer le fait qu'au bout de 48 h une mission terminee est archivee et suppri- 
mee de la memoire vive du systeme, quelle est la marche a suivre ? La notion de time event evo- 
quee precedemment repond a ce besoin. La transition de passage dans I'etat final est done 
declenchee par I'occurrence de after (48 h). 

Le diagramme d'etats de la classe Mission devient alors celui de la figure 8-16. 



create( nom, nature ) 



mooiner 

[1 



Change event' 



Time event- 



valider( dateDepartPrevue 
annulee 
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when ( dateCourante = dateDepartPrevue - 1 h ) 
annuler \^ 



r^jp} supprimee 



Non modifiable 



after ( 48h ) 



depart 



Figure 8-16 : Nouveaux ajouts surle diagramme d'etats de la classe Mission 
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II est possible d'indiquer plusieurs etats finaux avec des noms differents, afin 
d'augmenter la lisibilite du diagramme, ou simplement de distinguer des 
manieres differentes de detruire un objet. 

Pour l'instant, le diagramme d'etats que nous avons dessine represente bien la 
chronologie possible des evenements qui peuvent affecter les objets de la 
classe Mission, avec les differents etats correspondants. En revanche, il lui 
manque une partie importante : comment reagissent a leur tour ces objets lors 
des changements d'etats ? 

UML a prevu deux possibilites pour decrire les reactions d'un objet, et plus 

generalement ses traitements et ses operations : 

les effets associes aux transitions sont considered comme atomiques, c'est- 
a-dire ininterruptibles, ou encore instantanes par rapport a l'echelle de 
temps consideree. lis peuvent representer des appels d'operations sur 
d'autres objets, ou sur l'objet lui-meme, la creation ou la destruction d'un 
autre objet, ainsi que l'envoi d'un signal a un autre objet ; 
les activites durables (do-activity), au contraire, ont une certaine duree, 
sont interruptibles et sont done associees aux etats. On distingue les activi- 
tes continues (qui ne s'arretent qu'a l'arrivee d'un evenement faisant sortir 
l'objet de l'etat courant) et les activites finies (qui s'arretent de toute fa5on 
par elles-memes au bout d'un certain temps, ou lorsqu'une certaine condi- 
tion est remplie). 

Illustrons-le en ajoutant des effets et des activites sur le diagramme d'etats de 
la classe Mission. 



ETUDE DE CAS : AJOUT D'EFFETS ET D'ACTIVITES POUR LA CLASSE 
MISSION 

La definition d'une mission, a savoir I'affectation des commandes, d'un vehicule et d'un 
chauffeur, constitue une activite durable. En revanche, la creation d'une FeuilleDeRoute 
ou d'un SuiviMission, l'envoi d'un signal au repartiteur ou I'archivage de la Mission peuvent 
etre consideres comme de simples effets. Remarquez la notation particuliere proposee par UML 
pour l'envoi de signal, avec le mot-cle send. 
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Figure 8-17 : Ajout d'effets et d'activites sur le diagramme d'etats de la classe Mission 

Si nous voulons factoriser I'effet libererRessources qui se retrouve sur trois transitions, UML nous 
propose un raccourci sous la forme d'un effet d'entree declenche par le pseudo-evenement 
entry. A la figure 8-18, nous avons simplifie le diagramme d'etats de la classe Mission en sup- 
primant provisoirement I'etat Terminee ainsi que la transition declenchee par I'evenement tempo- 
rel after(48h). Par consequent, les trois transitions qui conduisent a I'etat final doivent porter I'effet 
libererRessources. Celui-ci peut alors etre factorise en entree de I'etat final : 



En attente 



annuler 



Non modifiable 



En cours 



Effet d'entree 



entry / libererRessources 



Figure 8-18: Exemple d'effet d'entree sur un etat final 

La meme notation existe bien sur egalement en sortie d'un etat : exit. 

Revenons maintenant sur la notion importante d'activite durable. Quand un objet se 
trouve dans un etat, soit il reste passif, et attend qu'un evenement le fasse changer 
d'etat, soit il execute une activite durable jusqu'a ce qu'elle soit interrompue par un eve- 
nement. Par exemple, dans I'etat En attente, on peut considerer que I'objet Mission se 
definit progressivement, jusqu'a ce que le repartiteur decide de le valider. L'activite defi- 
nirMission recouvre un traitement complexe consistant a enchainer les affectations de 
commandes, celles de ressources et les creations d'etapes. Elle nous permet de rester a 
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un niveau d'abstraction eleve avant d'entrer dans le detail. Si necessaire, on peut ensuite 
preciser I'activite en referengant un autre diagramme montrant de fagon detaillee I'interieur du 
traitement encapsule par I'activite. 

La figure 8-19 illustre cette maniere de decrire une activite de haut niveau. Vous remarquerez que 
les transitions entre etats ne sont pas forcement declenchees par des evenements. Une transi- 
tion declenchee implicitement lorsqu'un etat a termine son activite finie est appelee transition 
automatique. 



create) nom, nature 


) 


t \ 
En attente 


#— >| 


do / definirMission 
■A 



Activite 
et sa 
decomposition 



Point de sortie 



X 



En attente 



QO Erreur 



[ pas OK ] 



^ / send 

| repartiteur.tonnageEstime 

Affectation commandes £ * Affectation ressources 




Transitions 
automat iques 



Figure 8-19 : Sous-diagramme de /'operation definirMission 

Le deroulement nominal de definirMission consiste en I'enchaTnement des deux activites 
affectation commandes et affectation ressources, avec un resultat OK pour cette der- 
niere. Notez qu'une transition automatique peut porter une condition de garde, ainsi 
qu'une activite. Notez egalement I'utilisation du nouveau concept UML 2.0 de point de 
sortie (exit point) permettant de distinguer une sortie specifique (condition [pas OK]) de 
celle correspondant a la fin normale de I'activite. 

Comment savoir au niveau du diagramme d 'etats superieur que I'activite definirMission 
est en fait decrite par un sous-automate ? La encore, UML propose une notation 
particuliere, appelee indicateur de decomposition cachee, comme indique a la figure 8-20 : 
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create) nom, nature ) 




valider( dateDepartPrevue ) / ^ 
creerFeuilleDeRoute 



Point de 
sortie 



Indicateur de 
decomposition 



Figure 8-20 : Exemple d'indicateur de decomposition 

Remarquez que Ton retrouve la notation du point de sortie permettant d'exprimer le fait 
qu'a partir du sous-etat erreur, I'objet passe directement dans I'etat final 

Mais que se passe-t-il lors de I'occurrence de I'evenement modifier? Puisqu'il s'agit d'une 
transition propre, I'objet retourne dans I'etat En attente, mais comme celui-ci est detaille 
par un autre diagramme, il se retrouve en fait dans le sous-etat initial, a savoir Affecta- 
tion commandes. Ce qui est bien sur inutile : une modification d'affectation de ressour- 
ces obligerait a repasser en affectation de commandes. Pour traiter un evenement qui ne 
modifie pas I'etat courant de I'objet, UML propose un concept particulier : la transition 
interne, notee a I'interieur de I'etat, comme a la figure 8-21 . 



Transition 
propre 



modifier 




En attente 



do / definirMission 



En attente 



do / definirMission 
modifier 



Transition 
- interne 



Figure 8-21 : Transition propre et transition interne 

Une transition interne contient generalement un effet, comme sur I'exemple suivant, qui nous per- 
met de detainer les traitements a entreprendre en cas d'affectation ou desaffectation d'une com- 
mande. 
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modifier / 
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Affectation commandes 



affecte Cmd / incrTonnageEstime (poidsEstime) 
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Figure 8-22 : Transitions internes avec effet 
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PREFEREZ LES TRANSITIONS INTERNES AUX TRANSITIONS PROPRES ! 

Les transitions internes presentent une difference subtile avec les transitions 
propres. En effet, lors d'une transition propre, Fobjet quitte son etat courant, 
declenchant un eventuel effet de sortie (exit), puis retourne dans ce meme 
etat, et engendre le cas echeant un effet d'entree (entry). De plus, l'activite 
durable a l'interieur de l'etat est interrompue, puis redemarree. Au contraire, 
la transition interne n'a aucun effet de bord. 

Nous avons egalement evoque le fait que la transition propre ramene syste- 
matiquement dans le sous-etat initial si l'etat auquel elle s' applique est affine 
par un autre diagramme. 

Le diagramme d'etats consolide de la classe Mission est maintenant suffisam- 
ment complexe pour qu'il devienne indispensable d'introduire la notion d'etat 
composite. 

QU'EST-CE QU'UN ETAT COMPOSITE ? 

Un etat composite est un etat qui contient d'autres etats, appeles sous-etats 
ou etats imbriques. Ces derniers peuvent etre : 

sequentiels (ou encore disjoints), 
ou concurrents (aussi appeles paralleles). 
Les sous-etats sont a leur tour susceptibles d'etre decomposes. 



ETUDE DE CAS : AJOUT DE SOUS-ETATS POUR LA CLASSE MISSION 

Nous avons deja vu des sous-etats sequentiels avec la decomposition de l'activite definir- 
Mission. La notation particuliere de I'indicateur de decomposition cachee (figure 8-20) 
permet de rester au niveau d'abstraction superieur. II est cependant tout a fait possible 
d'inclure le diagramme montrant les sous-etats a l'interieur de l'etat englobant. 
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Figure 8-23 : Sous-etats sequentiels 

Le sous-etat initial (Affectation commandes) indique quel sous-etat sequentiel est atteint 
lors de I'entree dans I'etat englobant En attente. C'est le cas a la creation, mais aussi lors 
d'une modification alors que la mission a deja ete validee. Notez ensuite la difference 
entre les deux transitions suivantes : 

• celle qui est declenchee par annuler, et qui part du contour de I'etat englobant En 
attente : elle est heritee par chacun des sous-etats ; 

• celle induite par valider, et qui sort directement du sous-etat Prete, en traversant le 
contour de I'etat englobant : elle est specifique au sous-etat et non pas heritee. 

Si nous voulions maintenant detainer I'affectation des ressources, nous pourrions decrire 
plus avant le processus mis en ceuvre par le repartiteur : 

• chercher un vehicule libre de tonnage suffisant, 

• trouver un chauffeur qualifie pour ce vehicule. 

Pour gagner du temps, il se peut que le repartiteur veuille effectuer ces deux recherches 
en parallele, surtout s'il sait que la plupart de ses chauffeurs sont qualifies pour tous les 
vehicules. UML permet de decrire deux activites paralleles a I'interieur de I'etat Affecta- 
tion ressources, comme illustre a la figure 8-24. 
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Figure 8-24 : Exemple de sous-etats concurrents 

Les traits pointilles indiquent la separation en deux sous-automates concurrents. 

Notez qu'il taut initialiser chacun des sous-automates : I'etat initial est done compose du 
couple (Sans vehicule, Sans chauffeur). Normalement, I'etat final a I'interieur d'un etat 
composite permet de specifier que I'execution de I'activite de haut niveau est terminee. 
Quand il est atteint, une transition automatique partant de I'etat englobant est automati- 
quement declenchee. Dans le cas des sous-automates paralleles, e'est un peu plus com- 
plique : il faut que les deux activites soient terminees, dans n'importe quel ordre. Dans 
notre exemple, la transition qui part de I'etat englobant Affectation ressources vers I'etat 
Prete est dite de synchronisation, car elle ne sera declenchee que lorsque les deux sous- 
automates seront chacun arrives dans son etat final. 



Ne pas faire 



NE VOUS CROYEZ PAS OBLIGE D'UTTLISER TOUTES LES SUBTTLITES DES 
DIASRAMMES D'ETATS ! 

Comme vous avez pu le constater sur le petit exemple de la classe Mission, le 
formalisme du diagramme d'etats UML est tres puissant, mais aussi tres 
complexe ! Et encore, nous n'avons pas evoque : 

le pseudo-etat history, dont l'activation renvoie au dernier sous-etat actif 
d'un etat composite ; 

les evenements differes (defer) qui sont memorises pour etre traites 
dans un etat futur qui les acceptera, etc. 
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~~ Gardez a l'esprit que la plupart des diagrammes d'etats peuvent etre expri- 
mes de facon satisfaisante avec les concepts de base : etat, transition, condi- 
tion, effet, activite. 

Toutes les astuces de notation sont seduisantes, mais necessitent en contre- 
partie une expertise certaine de la part du lecteur, d'autant que les concepts 
avances sont ceux qui ont subi la plus grande evolution depuis les debuts 
d'UML, et qui sont les moins bien pris en charge par les outils... 

Valider les diagrammes d'etats avec les diagrammes d'interactions 

Nous avons insiste precedemment sur la complementarite entre : 
les diagrammes d' interaction (sequence et communication), 
et les diagrammes d'etats. 

Cette complementarite est fondamentale ; il est important de confronter ces 
deux points de vue, des que Ton dispose des diagrammes correspondants. 

En effet, les diagrammes d'etats apportent precision et exhaustivite, et permet- 
tent de valider et de completer les diagrammes d'interactions. lis peuvent 
egalement inciter a creer de nouveaux diagrammes d'interactions pour 
completer ceux qui existent deja. II faut toutefois verifier que les diagrammes 
d'etats des classes impliquees dans les diagrammes d'interactions prennent 
bien en compte tous les scenarios decrits, et qui plus est de facon correcte. 

Le schema suivant represente les relations entre les deux types de 
diagrammes. Prenons un diagramme de sequence simple mettant en jeu deux 
objets : a de la classe A et b de la classe B. L' interaction entre ces deux objets 
consiste en l'enchainement de deux evenements : 

suite a la reception de l'evenement evO, a envoie evl a b ; 

en retour, b envoie evl a a. 

Les diagrammes d'etats des classes A et B doivent forcement etre coherents 
avec cette interaction, meme s'ils integrent de nombreux autres comporte- 
ments. 

Nous les avons representes partiellement le long de la ligne de vie de chaque 
objet. Ainsi, l'objet a est dans l'etat EAO avant de recevoir evO, puis passe dans 
le nouvel etat EA1, apres avoir envoye evl a b. L'evenement evl doit etre 
admissible a ce moment-la par 1' automate de la classe B, qui va a son tour 
changer d'etat apres avoir repondu evl a a. De nouveau, cela signifie que, 
dans l'etat EA1, a doit etre capable de traiter ev2. Nous voyons done que Ton 
doit etre capable de suivre toutes les interactions entre objets sur les 
diagrammes d'etats des classes concernees ; ce sont des contraintes a verifier. 
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Figure 8-25 : Complementarite entre diagrammes de sequence et d'etats 



Confronter les modeles statique et dynamique 

Nous avons evoque au fil des chapitres 4, 7 et 8, les relations diverses qui exis- 
tent entre les principaux concepts du modele statique (objet, classe, associa- 
tion, attribut et operation) et les principaux concepts dynamiques (message, 
evenement, etat et activite). 

Les correspondances sont loin d'etre triviales, car il s'agit bien de points de 
vue complementaires, et non redondants. Essayons de synthetiser les plus 
importantes, sans pretendre a l'exhaustivite : 

un message peut etre un appel d' operation sur un objet (le recepteur) par 

un autre objet (Femetteur) ; 

un evenement ou un effet sur une transition peuvent correspondre a F appel 
d'une operation ; 

une activite dans un etat peut concerner F execution d'une operation com- 
plexe ou d'une succession d' operations ; 

un diagramme d' interactions met en jeu des objets (ou des roles) ; 
une operation peut etre decrite par un diagramme d' interaction ou d' acti- 
vite ; 

une condition de garde et un change event peuvent consulter des attributs 
ou des liens statiques ; 
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un effet sur une transition peut manipuler des attributs ou des liens 
statiques ; 

le parametre d'un message peut etre un attribut ou un objet entier. 



ETUDE DE CAS : ILLUSTRATION DES CORRESPONDANCES ENTRE 
MODELES STATIQUE ET DYNAMIQUE SUR LA CLASSE MISSION 

Commencons par les parametres des messages. L'exemple suivant montre que : 

• le parametre dateDepartPrevue (que Ton retrouve aussi ailleurs dans une condition de 
garde) correspond a un attribut de la classe ; 

• le parametre nom du message de creation correspond probablement a I'attribut reference. II 
taut done mettre a jour I'un des deux diagrammes pour harmoniser ; 

• le parametre nature du message de creation correspond en fait a la combinaison de la spe- 
cialisation et de I'attribut nature de la sous-classe MissionDeTournee. 



create( nom, nature ) 


En attente 
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Validee 


> 
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valider( dateDepartPrevue ) 



Parametre 
incoherent avec 
1 'attribute 



Parametre se 
traduisant par une 
relation de 
specialisation 



Mission 



reference 
dateDepartPrevue 
dateArriveePrevue 
commentaire 
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MissionDeTournee 
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Figure 8-26 : Exemples de correspondances entre parametres de messages et attributs 

Un deuxieme exemple va nous permettre d'observer d'autres correspondances : 

• I'affectation setDestination(agenceXX) illustre le fait qu'une activite sur une transition peut uti- 
liser des attributs ou des liens. Ici, I'affectation ne met pas simplement a jour un attribut de 
I'objet, elle cree un lien avec un objet de la classe Agence qui prend le role de destination 
par rapport a I'objet concerne de la classe Mission ; 

• le message tonnageEstime correspond au resultat d'un traitement realise par I'objet Mission. 
II s'agit done d'une responsabilite de la classe Mission, qui devrait se traduire ici a la fois par 
une operation de calcul et un attribut pour memoriser le resultat ; 

• le message valider(dateDepartPrevue) correspond directement a I'invocation de I'operation 
valider sur I'objet Mission concerne, avec comme parametre un des attributs deja repe- 
rtories. 
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Figure 8-27 : Deuxieme exemple de correspondences statique/dynamique 



COMPLETEZ LES DIASRAMMES DE CLASSES AVEC LES ATTRIBUTS ET OPE- 
RATIONS IDENTIFIERS GRACE A L'ANALYSE DYNAMIQUE ! 

II ne faut pas oublier de mettre a jour les diagrammes de classes, afin de pro- 
fiter de 1' analyse realisee avec les differents diagrammes dynamiques. 

Verifiez egalement la bonne affectation des operations : peut-etre faut-il les 
remonter s'il existe une super-classe. 
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ETUDE DE CAS : COMPLEMENTS SUR LA CLASSE MISSION 



Mission 



reference 
dateDepartPrevue 
dateArrrveePrevue 
commentaire 




Mission 



reference 
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Conseil 



F/'gure 8-28 : Complements suria classe Mission 

FONDEZ-VOUS SUR LE CONCEPT DE STABILITE POUR CHOISIR ENTRE 
STATIQUE ET DYNAMIQUE ! 

La notion de stabilite est tres importante en modelisation : on represente par 
exemple les elements les plus stables par des classes, et d'autres moins sta- 
bles par des etats ou des messages. On peut egalement dire que les associa- 
tions decrivent des liens stables entre classes et les messages des relations 
dynamiques entre objets. 



Phases de realisation du 
modele dynamique d'analyse 

Deux techniques permettent de modeliser la dynamique d'un systeme avec 
UML. 

La premiere consiste a decrire comment des instances des classes d'analyse 
communiquent entre elles pour produire un comportement global du systeme. 
On parle dans ce cas de collaboration entre objets, comprenant a la fois : 

une vue structurelle constitute des objets et des liens statiques entre ces 

objets, 

une vue dynamique appelee interaction, composee par les flots de mes- 
sages entre objets circulant sur les liens statiques. 
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Avec la deuxieme, on s'interesse au cycle de vie d'un objet d'une classe 
particuliere au fil de ses interactions avec le reste du monde, dans tous les cas 
possibles. Cette vue locale d'un objet s'appelle une machine a etats, decrivant 
comment l'objet reagit a des evenements en fonction de son etat courant et 
passe dans un nouvel etat. 

L' ensemble des cas d'utilisation decouverts lors de la capture des besoins 
fonctionnels guide toutes les vues dynamiques, en structurant les scenarios 
decrits par des interactions. 




Waarammes de dosses comDletes 

Figure 8-29 : Demarche d'elaboration du modele dynamique 



Comme nous l'avons dit au debut de ce chapitre, les modeles statique et dyna- 
mique sont tres fortement couples et doivent se construire par iterations 
successives, chacun completant 1' autre. 
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Figure 8-30 : Couplage entre les demarches des modeles statique et dynamique 



Chapitre Conception generique 

9 



Objectifs du chapitre 

Ce chapitre va vous permettre de voir UML en action lors de la conception. 
Rappelez-vous qu'UML permet de visualiser, de specifier, de construire et de 
documenter. Ces quatre aspects vont etre maintenant decrits pour l'activite de 
conception sur la branche droite du processus 2TUP. 

Nous allons done voir comment : 

elaborer 1' etape de conception generique ; 

connaitre les points de vue de modelisation utilises pour cette etape ; 
utiliser UML lors de cette etape ; 

organiser le modele logique en frameworks techniques ; 

utiliser les cas d' utilisation techniques pour demarrer la conception 

generique ; 

utiliser les design patterns d' architecture ; 
faire bon usage d'un generateur de code. 



Quand intervient la 
conception generique ? 

La conception generique consiste a developper la solution qui repond aux 
specifications techniques que nous vous avons presentees au chapitre 5. Cette 
conception est qualifiee de generique car elle est entierement independante 
des aspects fonctionnels specifies en branche gauche. La conception gene- 
rique reste done une activite de la branche droite. Cette etape de conception 
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constitue les preconisations qu'il vous faut inventer, en tant qu'architecte logi- 
ciel de SIVEx, pour que la dizaine de developpeurs qui y participe, utilise les 
composants, idiomes et frameworks les plus efficaces. 

Identiquement a notre remarque concernant la specification technique, la stan- 
dardisation des techniques de developpement, a laquelle nous avons assiste 
ces dernieres annees, rend cette etape moins consequente qu'avant. En effet, la 
diffusion de frameworks et de composants gratuits, tels qu'EJB, Struts ou 
JDO, propose en quelque sorte des architectures logicielles cles en main, et 
generalement de qualite, qu'il suffit de reutiliser. 

La conception technique constitue le niveau d' abstraction a atteindre. Les 
points de vue developpes sont les suivants : 

le point de vue logique, qui detaille les classes de la solution ; 

le point de vue d'exploitation, car les premiers composants d' exploitation 

du systeme sont concus a ce niveau ; 

le point de vue de configuration logicielle, qui trace les classes et les ver- 
sions necessaires pour fabriquer le systeme. 

La conception generique est terminee lorsque le niveau de detail des 
diagrammes donne une image suffisante des classes et des composants techni- 
ques a integrer dans le systeme. 

Le developpement d'un prototype peut succeder a la conception generique de 
maniere a en valider les principes par le codage et le test. Cette phase de 
prototypage est fortement conseillee, car la qualite d'une conception gene- 
rique conditionne generalement celle du developpement pour le reste du 
projet. 

La conception preliminaire consiste ensuite a appliquer les concepts generi- 
ques aux fonctionnalites du systeme et a integrer les composants techniques 
dans le systeme considere dans la perspective de son exploitation. 
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Figure 9-1 : Situation de la conception generique dans 2TUP 

En definitive, la conception generique permet de formaliser, sous la forme de 
classes techniques reutilisables, les regies de conception pour l'ensemble d'un 
systeme a developper. Ces regies definissent l'integrite de conception citee 
par Brooks [Brooks 90] comme condition de succes d'un projet. 

On peut encore considerer que la conception generique developpe le squelette 
technique d'un projet. Si ce squelette est robuste et bien concu, il pourra soutenir 
toutes les evolutions fonctionnelles possibles. Si, au contraire, il est mal concu et 
qu'il necessite par la suite de nombreuses retouches, la reprise des erreurs aura 
des repercussions pouvant se reveler tres couteuses pour la suite du projet. 

UTTLISEZ UML COMME LANSAGE ENTRE CONCEPTEURS 

En preambule a ce premier chapitre de conception, nous vous suggerons d'utili- 
ser UML comme langage de conception entre developpeurs. En effet, les con- 
cepteurs specifient d'abord les besoins techniques auxquels le systeme devra 
repondre, avant d'en developper la solution. UML se revele un langage de com- 
munication efficace pour a la fois specifier, esquisser et construire une concep- 
tion. 
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UML n'entre pas systematiquement en action avec un outil de type CASE 
(Computer Aided Software Engineering). C'est parfois sur la nappe d'une 
table de restaurant, lors d'une negotiation entre plusieurs concepteurs, que 
s'elaborent les meilleures solutions ! Aurions-nous pu imaginer un tel sup- 
port de communication avec du pseudo-code ? C'est par son universalite et 
sa relative simplicite schematique qu'UML est devenu l'outil des architectes 
et des concepteurs qui construisent l'integrite de conception d'un systeme. Si 
vous etes sceptique, nous vous conseillons d'essayer des maintenant. En tout 
etat de cause, nous vous suggerons de vous entrainer a toute occasion pour 
acquerir la pratique de la conception objet avec UML. 



Elements mis en jeu 

Diagramme de classes, frameworks techniques abstraits et concrets, 
mecanisme, 

design patterns, reutilisation de composants techniques, 

diagramme de composants, composants d' exploitation, composants de 

configuration logicielle, 

generateurs de code et outils CASE. 

Classes et frameworks techniques 

L'integrite de conception s'exprime sous la forme d'un ensemble de classes 
techniques que les concepteurs du projet vont par la suite reutiliser pour deve- 
lopper les differentes composantes fonctionnelles du systeme. A titre d'illus- 
tration, le mecanisme de controle des transactions peut etre congu par un 
ensemble de classes techniques reutilisees, quelle que soit F application envi- 
saged dans SIVEx. En d'autres termes, depuis 1' application de saisie des 
commandes jusqu'a l'edition des plans de transport, les applications de SIVEx 
reutiliseront, grace a la conception generique, les memes classes pour gerer 
leurs transactions. 

On constate cependant qu'une classe technique fonctionne rarement seule, 
c'est pourquoi le concept-cle de la conception generique est le framework 
technique. 
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FRAMEWORK TECHNIQUE 

Un framework est un reseau de classes qui collaborent a la realisation d'une 
responsabilite qui depasse celle de chacune des classes qui y participent 
[UML-UG 05]. Un framework technique ne concerne que les responsabilites 
de la branche droite du processus. 

A titre d'exemples, les produits Struts et JDO, precedemment cites, sont des 
illustrations de frameworks techniques, aujourd'hui distribues en Open 
Source. 



G 

Definition 



INTERFACE 

Au sens UML, une interface est un ensemble d' operations utilise pour speci- 
fier le service (ou contrat) d'une classe ou d'un composant [UML-UG 05]. 

Structurellement, une interface ressemble a une classe avec le mot-cle 
« interface », qui ne peut ni definir d'attributs, ni definir d' associations navi- 
gables vers d'autres classes. Par ailleurs, toutes les operations d'une inter- 
face sont abstraites. Ce concept UML correspond assez directement au 
concept d' interface dans Java. 



Un framework peut etre abstrait ou concret. Dans le premier cas, il est cons- 
titute d' interfaces. La reutilisation framework consiste alors a implementer 
ces interfaces, a charge pour le developpeur de comprendre et de respecter le 
domaine de responsabilite technique qui leur echoit. Un framework abstrait 
structure seulement le modele de configuration logicielle. II est compose de 
classes que Ton peut directement reutiliser dans un projet. Un framework 
concret determine a la fois le modele de configuration logicielle et le modele 
d' exploitation. En realite, un framework n'est pas forcement abstrait ou 
concret, il est plus souvent une combinaison d' interfaces a implementer et de 
classes a reutiliser. Au niveau du modele d' exploitation, il est livre sous la 
forme d'un package, d'un fichier JAR, WAR, EAR ou plus largement d'une 
bibliotheque. Dans le modele d' exploitation, un framework peut donner lieu a 
des composants distribues ou a des librairies partagees. 



Un framework represente generalement les mecanismes necessaires a l'imple- 
mentation d'une couche logicielle. Le package Swing de Java, les classes 
MFC de Microsoft, ou plus recemment le composant struts du domaine 
www.apache.org constituent des exemples de frameworks qui realisent la struc- 
ture technique de la couche de presentation. 



204 



UML en action 



Elaboration du modele logique de conception 

Les classes, les interfaces et les frameworks techniques representent les 
briques de construction d'un modele logique de conception generique. Les 
diagrammes de classes en constituent la trame centrale ; autour de celle-ci 
viennent se greffer differents diagrammes dynamiques en complement de 
l'etude du fonctionnement de la structure. 

La modelisation des classes de conception avec UML ne necessite pas de 
reproduire exactement la structure du code qui doit etre developpe a terme. La 
conception est avant tout un travail de reflexion et de communication. II s'agit 
done de s'appuyer sur un ensemble de schemas suffisamment precis pour 
exploiter les possibilites techniques d'une solution et d'en explorer les avan- 
tages et inconvenients. 

^ VALEUR ETIQUETEE 

Une valeur etiquetee est une extension des proprietes d'un element d'UML 
qui permet d'apporter de nouvelles informations de specification. 

On utilise frequemment les valeurs etiquetees pour alleger les diagrammes de leurs 
details d'implementation. A titre d'exemple, la valeur etiquetee serialized peut etre 
utilisee pour signifier que la classe repond aux mecanismes de serialisation Java. 
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«lnterface» 
Serializable 



<=> 



Document 



Figure 9-2 : Exemple d 'utilisation d'une valeur etiquetee 

UTTLISEZ LES VALEURS ETIQUETEES POUR DOCUMENTER DES MECANIS- 
MES RECURRENTS 

D'une part, l'utilisation des valeurs etiquetees allege et simplifie la defini- 
tion des diagrammes de conception. D' autre part, vous donnerez plus de 
coherence a votre conception, car chaque valeur etiquetee standardise, par- 
tage et factorise un meme mecanisme de conception. 

Tout mecanisme introduit doit faire l'objet d'une definition claire dans le modele. 
Nous avons introduit un stereotype de package « mechanism » pour y developper 
les diagrammes UML de documentation. Vous devrez notamment expliciter 
l'equivalence de chaque valeur etiquetee comme illustre a la figure 9-2. 
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ETUDE DE CAS : CONCEPTION D'UN F/?/WEWO/?K 
£>£" JOURNALISATION 

lllustrons maintenant la conception d'un framework technique avec UML. Nous prendrons pour 
cela un probleme simple, a savoir I'audit des operations effectuees sur les postes clients et ser- 
veurs. La specification des besoins d'audit precise les contraintes suivantes : 

• la mise en ceuvre de journaux synchronises entre les serveurs et les applications en activite- 
notamment dans le cas des clients lourds ; 

• la possibility de surveiller les erreurs par recuperation d'evenements SNMP (Simple Network 
Management Protocol), utilise ici pour la surveillance des pannes sur le reseau ; 

• le respect de formats standard pour faciliter I'exploitation des systemes de I'entreprise ; 

• faeces concurrent au meme journal sur le serveur, qui ne doit pas ralentir les taches appe- 
lates. 

Les schemas obtenus pour decrire les besoins en phase de specification technique sont decrits 
a la figure 9-3 et 9-4. Comme nous vous I'avons signale au chapitre precedent, ces schemas ne 
peuvent etre repris en I'etat pour la conception. 



JournalApplication 





Commande 


1 

genere 


Utilisateur 



TraceApplioative 



Figure 9-3 : Specification des besoins d'audit au niveau de la couche de presentation 



JournalSysteme 
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Figure 9-4 : Specification des besoins d'audit au niveau de la couche metier 

Les concepteurs desirent en I'occurrence disposer de la meme interface, que I'appel soit sur le 
poste client ou sur le serveur. Par ailleurs, le fait d'acceder aux journaux de traces homogenes 
sur les differents serveurs necessite de distribuer cette interface. 

Le deploiement du service en EJB 2.0 a ete choisi pour la simplicity des mecanismes qu'il pro- 
pose dans le cadre de cet expose sur la conception avec UML. Les techniques de modelisation 
utilisees dans cet ouvrage restent neanmoins applicables quelle que soit la technologie de distri- 
bution employee. 
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Pour chaque composant EJB, la declaration d'une distribution passe par la definition d'interfaces 
derivant de interface standard Remote. L'utilisation d'une valeur etiquetee {EJB} sur llnterface et 
d'une propriete {remote) sur les operations distributes permet d'abreger les mecanismes qui 
seront reellement mis en ceuvre dans le code. 



«lnterface» 
JournalSystemeDist 

EJB = stateless session} 



ftrace(nom Trace : String) : FichierTrace 
tracerj...) {remote) 
signaler(...} {remote} 



Implicitement 
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EJB 



JournalSystemeDistHome 



EJ BSession 

- a — 



EJBObject 
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«lnterface» 
JournalSystemeDist 



trace r(...) {throws remoteException} 
signaler(...) {throws remoteException} 



JournalSy steme DistBean 



ftrace(nomTrace : String):FichierTrace 



Classe de mise en ceuvre dc 
L'EJB (cote serveur) 



Figure 9-5 : Structure du mecanisme EJB 

Pour etre plus explicites, nous avons developpe la trame du code Java que le diagramme de la 
figure 9-5 implique : 

package SIVEx . frameworks . journalisation . interface; 
import javax . ejb . * ; 

public interface JournalSystemeDist extends EJBObject { 
void tracer ( String nomTrace, String message) 

throws RemoteException; 
void signaler (String message) throws RemoteException; 

} 
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package SIVEx . frameworks . journalisation . serveur; 
import SIVEx . frameworks . journalisation . interface; 
import javax . ejb . * ; 

public class JournalSystemeDistBean implements EJBSession { 
void tracer ( String nomTrace, String message) 

throws RemoteException { 

} 

void signaler (String message) throws RemoteException { 
} 

FichierTrace f Trace ( String nomTrace) { 
} 

} 



Introduction aux design patterns 

Les design patterns sont apparus dans les annees 1990. Les travaux de la 
« bande des 4 l » [Gamma 95] en ont produit le document fondateur. Cet 
ouvrage ainsi que des publications ulterieures constituent depuis des catalo- 
gues de reference pour les concepteurs objet. 

DESIGN PATTERN 

Un design pattern est une solution de conception commune a un probleme 
recurrent dans un contexte donne [UML-UG 05]. 

Dans les faits, les design patterns recensent les problematiques communement 
rencontrees lors des conceptions orientees objet. A titre d'exemple, on peut 
citer les problematiques suivantes : 

diminution du couplage, en vue de faciliter revolution du code, 
separation des roles, 

independances vis-a-vis des plates-formes materielles et logicielles, 
reutilisation de code existant, 
facilite d' extension. 

L'usage des design patterns apporte done evolutivite, lisibilite et efficacite aux 
developpements. C'est pourquoi leur emploi ameliore sensiblement le respect 
des prescriptions d' architecture [Bushmann 96]. Par ailleurs, ils offrent un 
transfert de competence rapide en conception orientee objet, dans la mesure 
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1. Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides, les quatre auteurs de 
[Gamma 95], souvent references en tant que GoF (Gang of Four). 
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ou ils representent pour les neophytes un catalogue des meilleures pratiques a 
adopter. A titre d' illustration, mais aussi parce que nous allons en faire usage 
dans la conception de SIVEx, nous presentons deux design patterns frequem- 
ment utilises en conception objet. 



Le design pattern « singleton » 

Le « singleton » [Gamma 95] est Fune des techniques les plus utilisees en 
conception orientee objet. II permet de referencer F instance d'une classe 
devant etre unique par construction. Certains objets techniques prennent en 
effet une responsabilite particuliere dans la gestion logique d'une application. 
C'est par exemple le cas d'objets comme le « controleur des objets charges en 
memoire » ou le « superviseur des vues », qui sont les seuls et uniques repre- 
sentants de leur classe. Ces objets sont le plus souvent publiquement accessi- 
bles. De tels cas de figure sont extremement frequents en conception objet, et 
le singleton est requis pour les concevoir. 

Le singleton repose sur Futilisation d'une operation de classe, getlnstance() : 
Instance, chargee de rapporter a l'appelant la reference de l'objet unique. De 
plus, le singleton se charge automatiquement de construire l'objet lors du 
premier appel. Le diagramme UML ci-dessous presente la forme generique 
d'une classe implementant un singleton. Vous remarquerez l'usage de la nota- 
tion UML pour un attribut et une operation de classe. 



Singleton 

instance : Singleton = null 




if(Jnstance = null) K 
Jnstance = new SingletonO; 
return _instance; 



Figure 9-6 : Structure du design pattern singleton 

Le singleton est utile au concepteur de SIVEx qui desire creer en local un seul 
et unique fichier de traces pour toute 1' application. De plus, le singleton qui 
repose sur une methode de fabrication implicite d'objet pour l'appelant, peut 
etre etendu et fournir un moyen de controle sur la creation d'instances. Dans 
l'exemple du framework de journalisation, un seul et meme fichier de traces 
doit etre cree par jour. Le concepteur peut done enrichir la methode de fabrica- 
tion getlnstancef ) pour ajouter un controle sur la date de creation comme dans 
le code ci-apres. Vous remarquerez que la classe standard java.util.Calendar 
utilise egalement un singleton pour renvoyer la date courante. 
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package SIVEx . frameworks . journalisation . serveur; 

import java . util . * ; 

public class FichierTrace { 

private Date _dateCreation; 
// realisation de 1' attribut de classe du singleton 
private static FichierTrace _instance 

// realisation de 1' operation de classe du singleton avec contrdles 
public static FichierTrace getlnstance () { 

// la classe Calendar utilise un singleton pour la date courante 
int day = Calendar . getlnstance (). get ( Calendar . DAY_OF_WEEK) , 

if ( _instance == null jj _dateCreation . getDay () .'= day ) { 
_instance = new FichierTrace () ; 

} 

return _instance; 

} 

// le constructeur est prive car le singleton doit etre le seul 



moyen 



}; 



// d' acceder a une instance de la classe. 
private FichierTrace () { 



} 



On a cependant prefere deleguer la capacite de creer de nouveaux fichiers de 
traces a une autre classe et utiliser de ce fait le design pattern « fabrication ». 



Le design pattern « fabrication 1 » 

Ce design pattern [Gamma 95] consiste a donner a une classe particuliere, la 
fabrique, la responsabilite de fabriquer les objets d'une autre classe, a savoir 
les produits. La figure 9-7 montre la structure de la fabrication. Vous y remar- 
querez la representation UML 2 d'un design pattern sous la forme d'une 
collaboration. 



1. Factory dans la version anglaise originate. 
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V Fabrication 
I 

l 



«lnterface» 
Fabrique 



fabricationf) : Produit 

5 



<lnterface> 
Produit 



FabriqueConcrete 


«create» 




ProduitConcret 


fabricationf) : Produit 


> 



return new ProduitConcretQ; 



Figure 9-7 : Structure du design pattern fabrication 

Au meme titre que le singleton, la fabrication est une technique souvent 
utilisee en conception orientee objet. Nous avons pris a titre d' illustration la 
journalisation sur le poste client. La classe Journal a pour responsabilite de 
fabriquer les fichiers de traces, et prend ainsi le role de facteur. On obtient 
alors le modele de la figure 9-8. 



«lnterface» 
Journal 



tracerQ 
signaler)) 



FileOutputStream 

(from java.io) 



Journal Local Imp 



ftraceQ : FichierTrace 



dateCreation : Date 



<asynch» tracer() 



// En local, un seul fichier de traces est cree par jour, 
if ( fichier == null ) 

fichier = new FicfiierTracef ...); 
else if ( fichier.dateCreation().before( hierMinuit) ) 
_fichier.fermer(); 

fichier = new Fich ierTrace( ...); 
return _ fichier; 



Figure 9-8 : Application d'une fabrication a la journalisation 
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Nous allons maintenant poursuivre la conception de la journalisation de 
SIVEx, en appliquant d'autres design patterns. 



ETUDE DE CAS : CONCEPTION D'UNE INTERFACE UNIQUE 
DE JOURNALISATION 

L'un des roles de la conception est de simplifier les interfaces de maniere a off rir le mode opera- 
toire le plus simple possible aux couches exploitantes d'un composant. Dans ce cadre, une inter- 
face de journalisation doit etre strictement identique, que le service soit local ou distribue. 
Comme les mecanismes de distribution, en I'occurrence EJB, induisent des contraintes de 
declarations etrangeres a la seule problematique de journalisation, nous avons recouru au 
design pattern « adaptateur » [Gamma 95]. L'adaptateur consiste a transformer par delegation 
les points d'entree d'un composant que I'on desire integrer a I'interface voulue par le concepteur. 



! Adaptateur 



Original 


masque 


Adaptation 


operationOriginel () 
operationOrigine2() 


«i 


operationAdapteeO 







operationAdaptee(signatureconforme) f^, 
{ operationOriginel (signatureSpecifique) 
operationOrigine2(signatureSpecifique) 

}; 



Figure 9-9 : Structure du design pattern Adaptateur 

Dans cette optique, I'interface des journaux a ete reduite a son strict necessaire : 

• tracer produit un message dans l'un desfichiers d'exploitation identifies par un nom de trace ; 

• signaler produit a la fois une trace et un evenement en vue d'alerter le systeme de supervi- 
sion du SI. 

Deux singletons implementent I'interface de journalisation, lis assurent et synchronisent la cohe- 
rence des traces entre serveur et client : 

• un journal systeme est charge d'adapter I'interface de distribution EJB au contexte local. La 
classe JournalSysteme joue done le role d'adaptateur. 

• un journal local est charge de produire les traces sur un fichier local (classe JournalLoca- 
llmp). 
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«lnterface» 
Journal 



tracer{ nomTrace : String, sessionld : long, nomService : String, texte : String) 

si gnaler( nomTrace : String, sessionld : long, nomService : String, texte : String, codeErreur : long) 
instanced : Journal 



EJB est utilise 
pour distribuer le 
service de 
journalisation du 
systeme 3 -tiers. 



JournalSysteme 



T 

egue i 



delegue a 
0..1 



«lnterface» 
JournalSystemeDist 



{EJB = sessionstateless} 



JournalLocalImp 



ftrace() : FichierTrace 



ftracef nomTrace : String) : FichierTrace 
tracer{. ..) {remote} 
signalerf...) {remote} 



figure 9-10 : Conception d'une interface unique et adaptation de /'interface distribute 

La distribution des services de journalisation offre une souplesse de repartition des traces. Les 
composants metier sont en effet clients du systeme de journalisation, au meme titre que les appli- 
cations. Cela permet d'obtenir une grande coherence entre les traces produites par les differen- 
tes composantes du systeme et de developper un outil precis de diagnostic d'erreurs. 



Construire de nouveaux design patterns 

En fonction des besoins de conception ou des pratiques en usage parmi les 
developpeurs, vous pouvez introduire vos propres design patterns. 

Dans le cas de SIVEx, le serveur de journalisation doit maintenir un fichier 
par nom de trace. De la sorte, les traces sont reparties sur plusieurs fichiers 
differents ce qui facilite le travail de recherche d'erreurs mene par l'ingenieur 
d' exploitation. Le journal systeme est done construit sur le modele d'une 
fabrication pilotee a la fois par un label - en 1' occurrence le nom de la trace - 
et par le maintien de references sur les instances deja creees. 

Faute de 1' avoir rencontre dans les publications existantes, nous avons intro- 
duit une variante du design pattern fabrication, que nous avons denommee 
« fabrication catalogued ». Ce design pattern dont la structure est illustree a la 
figure 9-11, definit un catalogue charge de fabriquer un article lors d'une 
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premiere demande de reference inexistante. Le catalogue conserve ensuite la 
reference de tous les articles fabriques, pour que lors d'une nouvelle demande 
de reference, le meme article deja construit soit renvoye. 



>' Fabrication Cataloguee 



«lnterface» 
Catalogue 



article(reference) : Article 



<lnterface> 
Article 



reference)) : ReferenceType 



7T 



CatalogueConcret 



article(reference) : ArticleConcret 



reference O 



garde en reference 



lesArticles 
0..1 



article = lesArticles. lookup( reference) 
if ( article == null ) { 

article = new ArticleConcret( reference); 

lesArticles. insertKey( reference, article); 

} 

return article; 



K 



ArticleConcret 



Figure 9-11 : Structure de la fabrication cataloguee 

Conformement aux besoins de journalisation, le journal systeme sert de fabri- 
cation cataloguee aux fichiers references par un nom de trace. Les regies de 
construction d'une trace sont cependant un peu plus complexes, puisqu'un 
nouveau fichier de trace est cree lors d'une modification de date. 



«lnterface» 
JournalSystemeDist 



{EJB=sessionStateless) 



ftrace( nomTrace : String) : FichierTrace 
tracer(...) {remote} 
signaler(...) {remote} 



Par extension du mecanisme EJB 
represents ici, la relation de composition 
concerne uniquement implementation 
du journal distribue. En effet, une 
interface ne peut ni contenir d'attribut, ni 
realiser dissociations. 



nomTrace : String 



0..1 



FileOutputStream 



7T 



FichierTrace 



dateCreation : Date 



trace r() {asynch} 



Figure 9-12: Application d'une fabrication cataloguee au journal systeme 
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INTESREZ LES DESIGN PA TTERNS DANS LE MODELS DE CONCEPTION 

II est important de connaitre et de documenter tous les design patterns que 
vous utilisez dans votre conception. A cet effet, nous avons introduit un ste- 
reotype de package : design pattern. 

Les design patterns du domaine public ont une reference bibliographique et 
seule leur structure statique a besoin d'etre rappelee. Les design patterns que 
vous avez construits pour la conception doivent presenter tous les diagram- 
mes statiques et dynamiques necessaires a leur comprehension. 

Conception dynamique d'un framework 

La conception ne peut se contenter d'une simple etude du modele structurel. 
Tout comme en analyse, il est necessaire d' examiner la dynamique du modele, 
en l'occurrence la facon dont les composantes du framework se synchronisent. 

UML offre differentes approches pour exprimer la dynamique. Nous avons 
choisi d'utiliser : 

un diagramme d' interaction (diagramme de sequence ou de communica- 
tion) lorsque le mecanisme etudie implique la synchronisation d'appels 
provenant de differentes classes ; 

un diagramme d' etats lorsque le mecanisme etudie est sous la responsabi- 
lite d'une classe qui va occuper plusieurs etats, avec des alternatives de 
transitions entre les etats ; 

un diagramme d'activite ou un diagramme global d' interaction, lorsque le 
mecanisme concerne est entierement englobe par une seule methode char- 
gee d'en derouler les etapes fonctionnelles. 

A titre d' illustration, un diagramme de communication permet ici d'etudier 
comment le journal local et les journaux distribues vont se synchroniser. 




Conseil 
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client -Journalisation 



1 .1 [ dateCreation = veille] reinitialiser 
^2.1 tr acer( nomTrace, ...} 



1 . tracer( nomTrace,.. .) 

2. signaler( nomT race,...) 



1.1.1 «create» 
1 .2 tracer 



instance : Journal 
Locallmp 



1.3 tracer) nomTrace,...) 
2 2 signaler( nomTrace 



local : Fichier 
Trace 



1.3.1 fTrace( nomTrace) 
1 .3.2 [ dateCreation = veille] reinitialiser 
2.2.1 tracer) nomTrace,... ) 



1 .3.1.1 [inconnu] «create>: 
1.3.2.1 «create» 
1 .3.3 tracer 



remote : Journal 
*" SystemeDist 



i 2.2.2 signaler 



: Alerteur 
SNMP 



nomTrace : 
FichierTrace 



Figure 9-13 : Dynamique de synchronisation entre journaux 

Nous avons utilise la notation decimale (numerotation des messages) pour 
decrire precisement Fenchainement des appels entre methodes. Ainsi, la succes- 
sion des appels du diagramme ci-dessus correspond au pseudo-code suivant. 



JournalLocallmp :: tracer (...) { 

if ( dateCreation .before ( hierMinuit) ) then 

reinitialiser () //l.l 
_fichier .tracer (...) //1.2 

JournalSystemeDist : : instance () .tracer (...) // 1.3 

} 

JournalLocallmp : : reinitialiser () { 

_fichier = new FichierTrace (...) // 1.1.1 

2 

JournalSystemeDist : : tracer (...) { 




FichierTrace _trace = f Trace (...) ; // 1.3.1 
if ( _trace . dateCreation .before ( hierMinuit) ) then 
reinitialiser () //1.3.2 
_trace. tracer (...) // 1.3.3 



} 



ETUDE DE CAS : CONCEPTION D'UN MECANISME ASYNCHRONE 

L'appel d'une operation du journal systeme correspond, comme on I'a vu, a un acces EJB sur le 
composant distribue charge de maintenir les differents fichiers de traces. Malheureusement, EJB 
2.0 ne prend en charge les appels asynchrones qu'au travers d'un EJB, dit « message driven », 
particulier a la norme 2.0. Ainsi, tout appel au composant distribue provoque une file d'attente 
qui peut ralentir I'execution des procedures du poste client. Or, I'envoi d'une trace n'implique 
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aucune donnee en retour au client ; I'execution du code client a done de fortes chances de se 
voir inutilement ralentie. 

Une facon de remedier au probleme consiste a utiliser la capacite multitache de Java que I'on va 
concevoir au travers d'un nouveau mecanisme d'asynchronisme, {asynchl qui s'appliquera aux 
operations des classes mises en ceuvre sur les serveurs. En I'occurrence, I'appel de I'operation 
tracer va declencher la creation d'une tache AsynchTracer, declaree comme classe imbriquee 
de la classe FichierTrace. La figure 9-14 schematise la structure associee au mecanisme d'asyn- 
chronisme. Vous remarquerez la notation que nous avons adoptee pour exprimer les classes 
imbriquees de Java et les methodes synchronized. 



FichierTrace 

{ asynch} 



dateCreation : Date 



tracerQ {asynch} 



«mechanism» 
asynch 



«lntertace» 
Runnable 



FichierTrace::AsynchTracer 



dateCreation : Date 



tracer)) 

synchronized _tracer() 



Figure 9-14: Structure du mecanisme {asynch} 



La classe imbriquee FichierTrace::AsynchTracer est une tache Java declenchee a I'appel de I'ope- 
ration tracer. Cette derniere operation se termine des que la tache est lancee, de sorte qu'elle ne 
sera pas bloquee par I'attente d'une ecriture sur le fichier et ne bloquera done pas le client. En 
revanche, la tache lancee attend le temps necessaire pour ecrire sur le fichier via I'operation 
Jracer. Le diagramme de communication de la figure 9-15 decrit cette dynamique et utilise une let- 
tre en tete de notation des messages pour differencier les flots appartenant aux deux taches. 



Client du FichierTrace 



A1 tracer)...) A1 .2 create (tracer) 
A1 .3 start 



maTrace : 
FichierTrace 




cible 



A1.1 create (this) 



B1.3.1.1 _tracer(...) 



tracer : Fichier 




Trace : AsynchTracer 





B1.3.1 run 



Figure 9-15 : Communication du mecanisme de synchronisation 
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package SIVEx. frameworks . journalisation . serveur; 

public class FichierTrace { 

// classe imbriquee Java 

public class AsynchTracer implements Runnable { 
private FichierTrace _cible; 
private String _message; 

AsynchTracer ( FichierTrace cible, String message) { 
_cible = cible; 
_message = message; 

} 

public void run() { 

_cible . _tracer ( _message) ; 

} 

} 

private Date _dateCreation; 
public void tracer ( String message) { 

AsynchTracer tracer = new AsynchTracer ( this, message) ; 
Thread task = new Thread ( tracer) ; 

Task, run (); // libere 1' appelant, car retour sans attente. 

} 

public synchronized void _tracer ( String message) { 

// traitement normal de 1' acces au fichier via le catalogue.. 



}; 



Organisation du modele logique de conception technique 

Nous allons maintenant revenir au processus 2TUP et examiner les points de 
vue sur lesquels s'appuie le modele. II existe en fait une analogie d'approche 
entre les branches fonctionnelle et technique, seuls les intervenants et la 
nature des objectifs changent. 

Comparons en effet les deux approches : 

sur la branche gauche, Fanalyste determine les besoins en recourant au 
modele de specification fonctionnelle. Sur la branche droite, l'architecte 
technique determine et structure egalement les besoins techniques suivant 
les couches du modele de specification logicielle ; 
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sur la branche gauche, Fanalyste detaille ensuite son probleme en classes 
au niveau de chacune des categories de son modele stracturel. Sur la bran- 
che droite, l'architecte technique construit pareillement des classes, des 
mecanismes et des design patterns au sein de frameworks techniques qu'il 
va organiser dans son modele logique de conception technique. 

Le modele de conception technique est done egalement organise par packages 
de classes qui representent les frameworks developpes pour resoudre les 
problemes purement techniques - cet aspect purement technique fait que la 
conception, a ce niveau, est qualifiee de generique. Le modele logique est 
done organise suivant les dependances qui s'etablissent entre frameworks 
techniques. 

La figure 9-16 indique Forganisation retenue pour l'etude de cas SIVEx. 
Notez la facon dont cette organisation de frameworks techniques est 
influencee par les couches logicielles dans lesquelles nous avons exprime les 
besoins. Cette influence est bien evidemment une consequence du perimetre 
des responsabilites techniques affectees a chaque package : par coherence et 
homogeneite en effet, une responsabilite technique doit concerner une seule 
couche logicielle. Le modele de conception technique ajoute aussi des 
services qui sont transverses aux couches. Le framework de journalisation est 
typiquement l'un de ces services transverses utilisables depuis toutes les 
couches logicielles. 



ETUDE DE CAS : ORGANISATION DES FRAMEWORKS TECHNIQUES 

L'organisation du modele logique reprend les couches logicielles. A chaque couche correspond 
un framework technique, en partie abstrait, qui definit des interfaces de realisation des responsa- 
bilites logicielles : 

• le noyau presentation definit les classes, les interfaces et les mecanismes de base pour rea- 
liser la gestion des objets en memoire en vue de leur utilisation par les utilisateurs ; 

• le noyau applicatif definit ces memes elements pour rafraichir les vues, charger les modeles 
de fonctionnement et controler les commandes d'une application ; 

• le framework EAI etablit les transformations de donnees necessaires a la synchronisation 
avec les progiciels de SIVEx et le reste du systeme d'information ; 

• le noyau metier definit les elements permettant d'identifier les objets metier et de les gerer en 
services distribues ; 

• le noyau d'acces aux donnees definit les mecanismes de chargement, de sauvegarde, de 
mise a jour et de recherche des objets persistants. 

Les autres frameworks realisent des services transverses et completent la conception des cou- 
ches logicielles. Les services correspondent aux problematiques de distribution, de securite, de 
journalisation et d'authentification. 
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1 






«technical framewwk» 
Noyau Presentation 




1 


Noyau Applicatif 









<technical fram«vork» 
EA1 



,--\ 



Noyau MM 



■-technical framework» 



«techrical framework» 

Journalisation 



Figure 9-16 : Organisation du modele logique de SIVEx (diagramme de packages) 

La definition des frameworks et des dependances doit obligatoirement completer ce diagramme 
de packages d'organisation du modele logique. En voici deux exemples : 

• Noyau Securite : framework de gestion des habilitations. II correspond aux besoins transver- 
ses des couches Application et Metier. 

Ce framework depend de I'authentification pour acceder aux informations relatives aux utilisateurs. 

• Acces aux donnees : framework en partie abstrait gerant I'acces aux donnees et le stockage 
en base de donnees. II couvre les besoins de la couche d'acces aux donnees. 

Ce framework depend de la journalisation pour gerer un journal des requetes d'acces a la base 
de donnees. 



Les contraintes de reutilisation dans la conception generique 

Au meme titre que les contraintes d' optimisation, les contraintes de reutilisa- 
tion interviennent lors de la conception. La reutilisation repond a plusieurs 
criteres qui sont : 
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l'avantage economique, correspondant au temps de developpement qu'il 
aurait fallu consacrer a F elaboration du composant ou a son equivalent 
dans le projet ; 

le gain en fiabilite : les composants du commerce sont reputes robustes. 
Lorsqu'il s'agit de composants maison, il faut parfois evaluer leur degre de 
confiance, ce qui requiert des efforts a prendre en compte ; 
les contraintes d' integration : les documentations, les exemples et le 
decouplage technique qui facilitent l'utilisation du composant doivent ega- 
lement etre evalues. 

Plagiant Moliere, nous adopterons la maxime suivante : 

IL FAUT REUTILISER POUR CONCEVOIR ET CONCEVOIR POUR REUTILISER ! 

Reutiliser pour concevoir s'entend pour ses avantages economiques. La 
seconde assertion se comprend mieux par F experience et merite quelques 
explications. 

En ajoutant effectivement l'exigence de reutilisation a notre conception, on 
impose : 

un minimum de documentation, 
une assurance de robustesse, 

le decouplage necessaire a l'extraction de composants et a leur capacite 
de test hors de tout contexte applicatif. 

Ainsi, meme si la reutilisation des parties de F application en cours de deve- 
loppement n'est pas requise, Fenvisager apporte implicitement des qualites de 
decouplage, d'evolutivite, de comprehension et de robustesse du code. Autant 
de proprietes qui vont permettre la diminution notable des phases ulterieures 
de recette et de mise au point. 

Concevoir pour reutiliser est d' autant plus pertinent que le developpement de 
la branche droite est par nature reutilisable. Par son caractere generique, la 
solution est en effet independante de toute fonctionnalite. De ce fait, le cycle 
en Y a ete concu pour favoriser la reutilisation de F architecture technique dans 
son ensemble. 

II est done bien dans Fintention des concepteurs de SIVEx de reutiliser globa- 
lement les memes concepts techniques pour toutes les applications. De la 
gestion du quai jusqu'a la comptabilite, la journalisation, la securite, les 
mecanismes d'acces aux donnees et de distribution, les interfaces du noyau 
metier, du noyau applicatif et de la presentation seront identiques. 

Remarquez enfin comment la cartographie des dependances entre les 
frameworks techniques est importante pour la reutilisation. C'est cette carto- 
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graphie qui permet de maitriser le couplage entre composants et d'ordonner la 
realisation des tests unitaires et d' integration. C'est encore cette cartographie 
qui rend possible la subdivision du modele de conception technique en sous- 
parties potentiellement reutilisables dans d'autres contextes que SIVEx. Un 
futur systeme de l'entreprise pourra par exemple reutiliser le framework 
d'authentification. En raison des principes de reutilisation de la conception, 
toute sous-partie doit done etre potentiellement reutilisable. Si Faeces aux 
donnees nous interesse, l'organisation du modele de conception technique 
nous indique qu'il faudra reutiliser egalement la journalisation et l'authentifi- 
cation, ou bien proceder a des adaptations. 

REUTILISER SANS COORDINATION 

Nous avons souvent rencontre des developpeurs consciencieux qui, appor- 
tant le plus grand soin a l'organisation de leur code, sont desoles de ne pas 
voir leur code reutilise. Inversement, des projets decidant de recuperer un 
ensemble logiciel repute reutilisable, ont connu a leurs depens un supple- 
ment de maintenance non prevu [Ezran 99]. 

Dans les deux cas, aucun effort n'a ete apporte a la coordination entre les 
createurs et les utilisateurs de la reutilisation. L' experience acquise en deve- 
loppement objet montre en effet que la reutilisation du logiciel impose 
d' organiser et de faciliter la concertation [Jacobson 97]. Les facteurs essen- 
tiels de reussite sont done a la fois : 

le respect des regies d' architecture par l'organisation soignee du modele, 
une implication de la direction pour consentir aux depenses d'empaque- 
tage en composants, 

l'existence d'un comite d'assistance a la reutilisation, aupres des projets 
en cours. 

Quand bien meme ces criteres ne sont pas respectes, la maxime « reutiliser 
pour concevoir et concevoir pour reutiliser » peut etre appliquee en tant que 
regie d' amelioration de la conception. Vous aurez en effet donne a votre 
conception les qualites attendues par un architecte logiciel : facilite d' integra- 
tion, robustesse et capacite d' evolution. 

Elaboration du modele d'exploitation de la conception technique 

COMPOSANT (DEFINITION UML) 

Dans UML, un composant est une partie physique et rempla5able du sys- 
teme qui realise un ensemble d'interfaces [UML-UG 05]. 
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Pour etablir un modele d' exploitation, nous avons besoin de distinguer deux 
niveaux de composant : les composants d' exploitation deja represented au 
chapitre 5, et les composants qui servent a la configuration logicielle. Nous ne 
retrouvons pas cette dichotomie parmi les stereotypes predefinis d'UML : 
« executable » represente un executable capable de fonctionner sur une des 
machines du systeme physique. Cette caracteristique en fait un composant 
d' exploitation ; 

« library » correspond a une librairie statique ou dynamique. Seules les 
librairies dynamiques peuvent etre assimilees a un composant d'exploita- 
tion dans la mesure ou elles sont explicitement installees par l'ingenieur 
d' exploitation. 

Les deux autres stereotypes que nous avons retenus s'apparentent a la configu- 
ration logicielle : 

« file » represente un fichier de code. Dans le cadre d'un developpement 
Java, la correspondance systematique entre une classe et un fichier fait que 
la representation des fichiers de code n'apporte aucune information sup- 
plementaire aux diagrammes de classes ; 

« table » correspond a une table definie pour une base de donnees. Nous 
savons egalement qu'il est rarement necessaire d'en venir a ce niveau de 
detail pour F exploitation. 

En conception generique, le modele d'exploitation montre l'organisation des 
composants correspondant aux differents/rameviwfcy techniques que Ton peut 
mettre en ceuvre. Pour etablir la vue des composants d'exploitation, nous 
avons defini les stereotypes ci-apres : 

« application » represente un executable directement accessible a un utilisa- 
teur. Un composant de ce type se deploie generalement sur un poste client ou 
sur un serveur d' applications. 

« EJB server » est un serveur EJB. Un tel composant distribue, sous la 
forme de fichier EAR, se deploie generalement sur une machine de type 
serveur d' applications. 

« DB engine » constitue un moteur de base de donnees. 
« DB instance » correspond a une instance de la base de donnees, en principe 
un ensemble de tables et d'utilisateurs concus dans un cadre fonctionnel precis. 
« EAI broker » correspond au serveur des messages de transmission des 
echanges entre les applications du SI. 

« EAI adapter » correspond aux terminaux recepteurs/emetteurs de ces 
messages qui realisent le travail de mise a jour au sein des applications. 

La vue des composants d'exploitation complete la conception generique. Ce 
point de vue permet d'identifier les premiers elements du systeme logiciel et 
definit les regies de deploiement et d' integration des differentes composantes 
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de SIVEx. La vue d' exploitation precise par exemple l'ordre dans lequel 
l'exploitant doit initialiser les applications en fonction de leurs dependances 
reciproques. 



ETUDE DE CAS : MODELE D'EXPLOITATION 
DE LA CONCEPTION TECHNIQUE 



Voici comment nous avons choisi d'organiser les composants generiques qui devront etre inte- 
gres au prototype de validation de la conception generique : 

• pour des raisons de performances, la base de donnees du referentiel metier et le referentiel 
des informations d'integrite sont separes ; 

• le composant d'acces aux donnees correspond a la partie generique du framework qui 
pilote la connexion a la base de donnees ; 

• le composant de journalisation correspond a la partie distribute du framework de synchroni- 
sation des traces ; 

• le superviseur de la distribution est le chef d'orchestre des composants, il est notamment 
charge de demarrer tous les autres composants distribues. La relation de demarrage consti- 
tue une dependance particuliere. C'est pourquoi nous avons introduit le stereotype « start ». 



« DB lnstance> 

Referentiel 

d'integrite 

— A 



«EJB server» 

Superviseur 

d'integrite 

if — 



«start» 



« DB lnstance» 
Referentiel SIVEx 



-IK- 

I 
I 



«EJB server» 
Acces donnees 



«EJB server» 
Journal systeme 



«EJB server» 

Superviseur 

distribution 



CD 



Figure 9-17. : Structure de la vue d 'exploitation du modele de conception technique 
(diagramme de composants) 

A cette vue viendront s'ajouter ulterieurement les composants RMI metier et EAI qui ne sont pas 
definis dans le cadre de la conception generique. 
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Elaboration du modele de configuration logicielle 
de la conception technique 



G 

Definition 



SOUS-SYSTEME 

En UML, un sous-systeme correspond a un regroupement d'elements de 
modelisation dont le but est de fournir une meme unite de comportement au 
sein du systeme [UML-UG 05]. 

Un sous-systeme est represente par un package portant le mot-cle subsystem, 
qui ne regroupe pas forcement des composants comme ont pu le suggerer les 
premieres versions d'UML, ou certains outils CASE. Une premiere ebauche 
de decoupage en sous-systemes nous est d'ailleurs fournie par 1' organisation 
en frameworks techniques du modele logique ou de maniere plus macrosco- 
pique en associant un sous-systeme a chacun des deux progiciels choisis pour 
SIVEx. 

II peut etre interessant de developper le point de vue de la configuration logi- 
cielle, afin d'identifier les sous-ensembles pouvant se fabriquer et s'utiliser 
independamment les uns des autres. Un sous-systeme se caracterise done par 
un procede de fabrication independant. II s'agit par exemple du fichier make- 
file ou du fichier projet de votre plate-forme de developpement. Le sous- 
systeme se caracterise en outre par un numero de version qui fixe son etat 
d'evolution au sein de la construction globale du systeme. Par l'usage que 
nous en faisons, le sous-systeme devient done F element de structuration du 
modele de configuration logicielle. Le decoupage en sous-systemes nous sert 
a identifier les dependances de compilation des EJB, les dependances 
d' implantation des sources Java et les regroupements en fichiers JAR, EAR ou 
WAR. 

La structure en sous-systemes etablit generalement une correspondance 
directe avec les composants d' exploitation qui representent autant de cibles de 
fabrication, et avec tous les sous-ensembles de classes qui sont reutilises par 
les differents composants. 

Par experience, le modele de configuration logicielle n'a d'interet que pour 
des systemes consequents tels que SIVEx. Lorsqu'il s'agit de realiser des 
applications qui, a terme, ne produisent qu'un ou deux composants de 
deploiement, 1' expression d'un modele de configuration logicielle est plus que 
facultative. 
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ETUDE DE CAS : MODELE DE CONFIGURATION LOfilClELLE 

Le modele de configuration logicielle est developpe au niveau de la conception technique. Les 
sous-systemes identifies sont autant de cibles de fabrication independantes, de maniere a pou- 
voir etre reutilises par differents projets, par exemple dans le cas de SIVEx : 

• le sous-systeme « Schema d'integrite », qui correspond a la fabrication des tables et des 
EJB permettant de fabriquer et de lancer en exploitation la base de donnees servant de « 
referentiel d'integrite » ; 

• le sous-systeme « Journalisation », qui concerne I'ensemble des packages Java et des 
composants EJB fournissant les services de journalisation ; 



Prise en compte de la generation de code 

La conception generique consiste a developper le squelette technique d'un 
projet, garant de son integrite conceptuelle future. Comme nous l'avons deja 
mentionne, la conception generique se compose de frameworks techniques 
plus ou moins abstraits. 

Le framework d'acces aux donnees est par exemple abstrait parce qu'il est 
essentiellement compose d'interfaces. Parmi ces interfaces, IDataClasseBD 
represente toute structure echangee avec la base de donnees. En conception 
detaillee, cette interface sera implemented par rapport aux besoins fonction- 
nels des applications de SIVEx. Elle donnera lieu a des implementations en 
partie calquees sur la structure des classes d' analyse. Le diagramme ci-apres 
illustre notre exemple : 




<<lnterface>> 
IDalaClasseBO 



-<r~w 



Projection sur la 
couche d'acces aux 



DataVehicuie 



noCarteGnse Stnng 
nolmmatnculation Stnng 
mi 

oidT/peVehicule OID 



DataTypeVehicule 
nomType String 
chargeMin : int 
chargeMax : int 



Figure 9-18: Correspondance entre le modele d'analyse et un framework technique 

On peut done constater que 1' implementation des frameworks abstraits se fonde 
sur des informations deja disponibles dans le modele d'analyse. Par ailleurs, la 
constitution manuelle du code Java s'avererait particulierement penible, tant 
pour la creation - car il s'agit d'une interpretation quasi-automatique d'informa- 
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tions deja disponibles dans d'autres modeles - que pour la maintenance. En 
effet, toute modification du modele doit entrainer la mise a niveau correspon- 
dante des differentes lignes de code. 

L' implementation des frameworks abstraits a partir des definitions fonction- 
nelles fait done l'objet d'une ecriture de code repetitive et fastidieuse a main- 
tenir. Si la variabilite reside dans les informations que comportent les modeles 
UML, le generateur de code s'avere particulierement efficace. Cette approche 
est aujourd'hui promue par l'OMG sous la denomination MDA (Model 
Driven Architecture) comme nous vous l'avons deja explique au chapitre 2 de 
cet ouvrage. 

II existe des contextes pour lesquels la generation de code complete tres utile - 
ment la conception generique. 



CE QU'ON PEUT ATTENDRE D'UN GENERATEUR DE CODE 

Un generateur de code accompagne la plupart du temps l'outil CASE que 
vous utilisez pour editer vos modeles UML. De ce point de vue, on peut deja 
separer les outils CASE en trois families : ceux qui vous permettent de deve- 
lopper vos propres generateurs, ceux qui vous livrent des generateurs munis 
de capacites de parametrage et les outils de derniere generation qui sont con- 
formes a l'architecture MDA. 

Si vous estimez que votre projet doit inclure de la generation de code et qu'il 
doit se conformer a une conception generique particuliere, ecartez immediate - 
ment les outils qui ne vous donnent pas la possibilite d'obtenir votre propre 
generateur. Conformement a ce qui vous est explique au paragraphe precedent, 
le generateur de code complete votre conception, et non l'inverse. En conse- 
quence, les generateurs foumis par defaut ne sont utiles que s'ils peuvent 
s' adapter a vos propres contraintes de conception. 

Un generateur de code parametrable doit vous permettre d'acceder a toutes 
les informations du modele UML et de produire des fichiers qui restituent 
cette information sous le format de votre choix. Avec un generateur, vous 
pouvez done aussi bien creer un rapport texte qu'un fichier de code Java. 
Notez que certains generateurs peuvent se coupler avec les suites bureauti- 
ques et produire des documents de travail directement issus du modele. Le 
recours aux generateurs est done un excellent moyen pour synchroniser 
revolution d'un modele avec le code et la documentation qu'il produit. 
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Nous avons retenu trois niveaux de complexite de generation : 

1. Generer les squelettes : c'est le niveau le plus facile et le plus repandu 
pour lequel le generateur recupere les classes, leurs attributs, les opera- 
tions et les signatures. Le generateur produit alors un fichier Java pour 
chaque classe incluant des methodes vides a completer manuellement. 

2. Generer les mecanismes systematiques : c'est le niveau le plus efficace 
pour completer une conception generique. Les classes sont generees avec 
des methodes specifiques aux mecanismes du framework technique vise. 
La difficulte de ce niveau est le parametrage specifique que vous devez 
ajouter pour avoir un controle plus precis sur les differents cas de figure 
rencontres. 

3. Generer le corps des methodes fonctionnelles : pour les operations liees a 
un diagramme d' interactions ou les classes liees a un diagramme d'etats, 
le generateur recupere en outre les informations du modele dynamique 
afin de generer en Java les methodes equivalentes a la description UML. 

Dans tous les cas, le generateur doit etre incremental pour etre operationnel, 
ce qui signifie que toute nouvelle generation de code doit preserver le code 
que vous avez ajoute manuellement. 

Un generateur de code doit done repondre aux trois qualites suivantes : 
il doit permettre de coller a votre conception generique ; 
il doit etre capable d'implementer tout xm framework abstrait a partir des 
informations deja disponibles dans le modele d' analyse ; 
il doit etre incremental. 

Avec de telles specifications, le generateur devient un projet dans le projet. II 
demande de proceder a une analyse, a une conception, puis a un codage. II 
implique done un investissement de ressources. Un bon critere de rentabilite 
consiste a mesurer Finteret d'un generateur de code. A cet effet, vous multipliez le 
nombre de classes d' analyse par le nombre frameworks concemes. Un interet 
de 150 a 200 classe*framework vous foumit alors une limite de decision. Au-dela 
de cette limite, nous vous conseillons fortement d'utiliser la generation de code. 
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ETUDE DE CAS : CALCUL DE L'OPPORTUNITE D'UN GENERATEUR 
DE CODE 

Recensement des frameworks techniques de SIVEx impliques par la generation de code : 

• framework d'acces aux donnees, 

• framework de distribution, 

• framework du noyau client, 

• outre les frameworks, on inclut les scripts des tables relationnelles. 
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Calcul de I'interet a la generation de code : 4 * 50 classes issues de I'analyse de SIVEx : 
Interet a la generation = 200 classe*framework 

Nous avons done interet a developper un generateur pour completer la conception generique. 
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NE PAS SOUS-ESTIMER LE COUT D'UN GENERATEUR DE CODE 

Le constat que nous avons pu faire sur les differents projets oil nous sommes 
intervenus est le suivant : la generation de code est encore trop rarement 
exploitee, voire parfois abandonnee suite a F evaluation des moyens offerts par 
les outils CASE. Nous avons cependant deja pu experimenter des generations 
de code rentables dans au moins trois contextes de developpement differents. 

Premier conseil : ne jamais sous-estimer le cout ou les risques accompagnant 
un outil de generation de code. Le developpement d'un generateur est un pro- 
jet dans le projet qui necessite les memes criteres de suivi : pilotage par les ris- 
ques, developpement par increments et construction autour d'un modele. 

Le second conseil consiste a ne debuter I'analyse du generateur de code 
qu'une fois le modele de conception technique stabilise. II est vain en effet 
d'anticiper ou d'evaluer des generateurs de code etrangers a votre conception. 



Developpement d'un prototype 

Vous avez con§u tous les frameworks techniques qui vous permettront de 
repondre aux specificites techniques de votre systeme. Vous avez eventuelle- 
ment developpe en sus les generateurs qui en facilitent l'implementation. 

Rappelons encore que F architecture technique ainsi obtenue garantit Finte- 
grite conceptuelle de tous vos futurs developpements. Vous contribuez ainsi 
non seulement a une bonne partie du travail de conception, mais apportez 
egalement les meilleurs savoir-faire a reproduire pour le reste du projet. 

DEVELOPPEZ UN OU PLUSIEURS PROTOTYPES COMME PREUVE DE CONCEPT 
Sachant qu'une conception evolue encore lors de son implementation et que 
tout changement concernant la conception generique devient couteux en 
phase d' implementation, vous avez interet a developper des maintenant un 
prototype d' architecture. Vous procederez ainsi le plus rapidement possible 
aux mises au point qui s'imposeront a votre conception generique. 

La question qui se pose ensuite est la suivante : « Que mettre dans un proto- 
type ? ». Sachez que Fensemble de vos prototypes doit repondre aux fonction- 
nalites techniques demandees par le systeme. Dans le cadre de SIVEx, le 
prototype doit au moins valider : 
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le mecanisme CRUD des objets (Create, Retrieve, Update, Delete) depuis 
la presentation jusqu'a la base de donnees, 

les transformations d'objets entre les couches : passer d'un objet de pre- 
sentation a un objet de distribution puis a un objet metier, 
les mecanismes d'authentification et d'habilitations, 
l'integrite des donnees sur le serveur et sur le poste client, 
les synchronisations EAI entre applications, 
les mecanismes de presentation. 

Le prototype peut done viser fonctionnellement un simple editeur des 
commandes et des clients de SIVEx en synchronisation avec SAP R3 et 
SIEBEL. Le prototype doit de plus disposer d'un mode de presentation multi- 
vues pour couvrir tous les aspects techniques. Enfin, le prototype valide et 
prepare les trois niveaux de tests requis a la recette technique du systeme : 

il inclut le test unitaire des composants techniques pris un a un ; 

il prepare les tests d' integration dans le cadre de la preparation au develop- 

pement du systeme complet ; 

il repond deja aux specifications techniques, et notamment au respect des 
temps de reponse et des exigences de montee en charge. 

Le prototype valide et termine eventuellement l'etape de conception gene- 
rique. Nous sommes maintenant arrives au terme de ce chapitre et allons en 
recapituler les phases de realisation. 



Phases de realisation 
en conception generique 

La conception generique avec UML s'appuie sur le developpement de 
frameworks repondant aux specifications techniques. Aujourd'hui, la concep- 
tion orientee objet consiste a recourir aux design patterns ainsi qu'a schema- 
tiser les mecanismes les plus utilises. L organisation en architecture technique 
puis en composants doit ensuite repondre a des objectifs de reutilisation, de 
fabrication et de deploiement. 

Le detail du processus suggere en conception generique est le suivant : 

1. Elaboration du modele logique de conception technique : concevez les 
frameworks techniques : 

schematisez a l'aide de diagrammes de classes et d' interactions les design 
patterns que vous utiliserez ; 

representez de la meme facon les mecanismes de votre conception et 
identifiez-les avec des valeurs etiquetees ; 
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identifiez et schematisez avec UML les frameworks techniques : reutilisez 
pour concevoir et concevez pour reutiliser ; 

organisez le modele logique de conception technique - le decoupage en 
frameworks. 

2 Elaboration du modele d' exploitation de conception technique : concevez 
les composants d' exploitation : 

identifiez les composants d' exploitation correspondant aux frameworks 
techniques ; 

organisez le modele d' exploitation. 

3 Seulement, si l'ampleur du projet le justifie, elaboration du modele de 
configuration logicielle de conception technique : concevez les composants de 
configuration logicielle : 

identifiez les sous-systemes de fabrication des composants d' exploitation, 
en fonction des classes et des frameworks techniques disponibles ; 

organisez la configuration logicielle, en precisant les dependances entre 
sous-systemes ; 

developpez les composants de chaque sous-systeme si necessaire. 

4 Developpez optionnellement un generateur de code (c'est un projet dans 
le projet) : 

analysez a partir des resultats de la conception generique ; 
concevez ; 
implementez ; 
testez. 

5 Developpez un prototype : 
identifiez les objectifs du prototype ; 
implementez la conception generique ; 
integrez optionnellement le generateur de code ; 
testez ; 

mettez au point la conception generique et eventuellement le generateur de 
code. 

La reutilisation doit rester un leitmotiv pour toute cette activite, meme si elle 
n'est pas effectivement requise. Certains contextes justifient egalement de 
developper un generateur de code pour faciliter 1' implementation des 
frameworks abstraits. 

II est fortement recommande de mettre en ceuvre un ou plusieurs prototypes pour 
valider les decisions prises lors de cette phase essentielle pour le reste du projet. 
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Figure 9-19 : Construction de I'etape de conception generique 



Chapitre Conception 
1 0 preliminaire 




Objectifs du chapitre 



Nous allons maintenant etudier le role d'UML lors de l'etape de conception 
preliminaire. Les diagrammes UML servent ici plus particulierement a cons- 
truire et a documenter la fafon dont le developpement de la solution doit etre 
organise. 

Nous allons voir comment : 

elaborer la conception preliminaire avec UML ; 

developper les vues preconisees pour cette etape ; 

organiser un developpement objet et d' integration EAI avec UML ; 

construire les composants d'une architecture 3-tiers ; 

identifier et construire les applications d'un systeme d'entreprise ; 

identifier et construire un composant metier. 



La conception preliminaire est certainement l'etape la plus delicate du 
processus 2TUP car elle en represente le cceur. C'est en effet a cette occasion 
que s'effectue la fusion des etudes fonctionnelles et techniques. En conse- 
quence, plusieurs activites doivent coexister. II convient de : 
passer de 1' analyse objet a la conception, 

integrer les fonctions metier et applicatives du systeme dans 1' architecture 
technique, 

adapter la conception generique aux specifications fournies par 1' analyse. 



Quand intervient la conception preliminaire ? 
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La conception preliminaire est avant tout affaire d' organisation ; elle s'appuie 
sur les points de vue de specification fonctionnelle et structurelle de F analyse, 
mais egalement sur les frameworks de la conception technique. Elle se 
termine lorsque la conception est organisee suivant : 

son deploiement cible, 

son modele d' exploitation, 

son modele logique. 




Figure 10-1 : Situation de la conception preliminaire dans 2TUP 

Le processus global de conception est un processus a information croissante 
dont Fetape de conception preliminaire est la phase d' organisation. Le 
processus de conception combine differents points de vue de modelisation 
qui, a partir du resultat que Ton souhaite obtenir, remontent jusqu'aux details 
de fabrication en langage objet. 

Le premier niveau de conception d'un systeme est son deploiement car 
c'est generalement Forganisation des environnements de travail sur un 
reseau qui est la plus immediatement definie. Le diagramme de deploie- 
ment UML suffit ici a documenter ce niveau. 

A partir du deploiement, on est capable de definir les composants qui 
seront administres par l'exploitant du systeme. On concoit ici le modele 
d' exploitation en integrant les resultats de la conception generique. Les 
developpeurs doivent egalement definir les interfaces qui constituent le 
lien entre les composants, et enumerer les interfaces utilisateur qui corres- 
pondent aux besoins exprimes par l'analyse. 

La fabrication des composants d' exploitation recourt a differents outils, en 
l'occurrence Java, SQL et un atelier de fabrication d'ecrans. La conception 
s'effectue ici avec des diagrammes de classes UML et les classes doivent 
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etre organisees suivant des categories de conception. La conception preli- 
minaire s'arrete a la definition de cette organisation et c'est en conception 
detaillee que Ton developpe precisement le contenu de chaque categoric 
A ce niveau, le developpeur doit encore definir les interfaces des catego- 
ries et apporter plus de precisions aux interfaces utilisateur. L' ensemble de 
ces interfaces assure le passage de 1' analyse a la conception. 

L' organisation des classes de conception, ainsi que la connaissance des 
composants d' exploitation a developper, permettent en final d' organiser la 
configuration logicielle en sous-systemes. 

Les liens avec 1' analyse consistent a elaborer les interfaces a partir des cas 
d' utilisation, et a integrer les classes d' analyse dans le modele logique de 
conception. Ceux avec la conception generique resident dans 1' insertion des 
elements du modele deja concus, suivant les points de vue logique et d' exploi- 
tation. A 1' image du cone qui vous a ete presente pour illustrer le developpe- 
ment incremental, le schema ci-dessous resume le processus envisage pour la 
conception. 




Figure 10-2 : Le processus de conception a information croissante suivant les points de vue 

L organisation suivant le point de vue logique permet d'isoler les elements de 
developpement. Cette caracteristique qui suit les principes d' architecture et 
d'orientation composants peut aussi devenir une opportunite de developpe- 
ment parallele en sous-projets. 
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Elements mis en jeu 

Modele de deploiement, postes de travail, style d' architecture a niveaux, 
modele d' exploitation, applications, composants metier et instances de 
base de donnees, 

interfaces de composants, interfaces utilisateur, interfaces EAI, facade, 
modele logique, diagramme de classes, classes et categories de concep- 
tion, distribution du modele logique sur les couches, 
modele de configuration logicielle. 



Developpement du modele de deploiement 



© 

Definition 



Le deploiement d'une solution client/serveur se construit sur la definition des 
postes de travail. 

POSTE DE TRAVAIL 

Le poste de travail represente un ou plusieurs acteurs pouvant etre localises 
sur une machine d'un type particulier et remplissant une fonction identifiee 
dans l'entreprise. Le poste de travail ne represente pas forcement une 
machine physique, mais peut consister en plusieurs machines, a condition 
qu'elles donnent lieu au meme type de deploiement. 

A un acteur de 1' analyse correspond generalement un poste de travail, mais ce 

n'est pas toujours le cas : 

le chauffeur disposant d'un terminal portable correspond a un poste de tra- 
vail ; 

si Ton imagine qu'il existe deux types de terminaux necessitant deux con- 
figurations logicielles differentes, deux postes de travail correspondent a 
l'environnement du chauffeur ; 

1' administrate™ du systeme n'a pas de poste de travail particulier mais 
peut intervenir a partir de n'importe quel poste. 

La notion de poste de travail peut cependant etre quelque peu bouleversee par 
la generalisation des deploiements en client leger. En effet, au travers de la 
notion de portail plusieurs applications sont potentiellement accessibles, voire 
atteintes de maniere transparente a 1' utilisateur par des techniques de syndica- 
tion. Cette evolution technologique nous amene a associer la notion de poste 
de travail a l'ensemble des applications Web que Ton desire rendre accessibles 
pour un acteur particulier du systeme. La definition des postes de travail dans 
ce cadre constitue alors une excellente analyse des acteurs et des droits que 
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Ton doit declarer au travers des mecanismes de « single sign-on » d'un 
portail. 

Les modeles de deploiement et de configuration materielle s'expriment tous 
deux a l'aide d'un diagramme de deploiement. Cependant, ils n'expriment pas 
tout a fait le meme niveau de description. 

Le modele de configuration materielle a ete utilise au chapitre 5 pour 
exprimer les contraintes de mise en ceuvre au niveau physique. On y 
trouve les nceuds et les connexions physiques du systeme, qui sont les dif- 
ferents types de machine connectes par des moyens divers. Le modele de 
configuration materielle permet de specifier, de documenter et de justifier 
tous les choix d' organisation physique en fonction des machines dediees 
aux diverses fonctions techniques du systeme. 

Le modele de deploiement considere plutot chaque nceud comme un poste 
de travail. II exprime la repartition physique des fonctions metier du sys- 
teme et permet de justifier la localisation des bases de donnees et des envi- 
ronnements de travail. Le modele de deploiement aide a preciser la 
qualification des postes client, des reseaux et de leur securite physique, par 
rapport a des criteres fonctionnels. 



ETUDE DE CAS : DESCRIPTION D'UN DEPLOIEMENT A 3 NIVEAUX 

Le deploiement se repartit suivant les deux niveaux central et departemental de I'entreprise 
[Orfali 94]. Les postes de travail s'articulent ainsi soit autour du serveur central, soit autour d'un 
serveur d'agence. Un serveur Web est dedie a la consultation distante des clients. 

Vous remarquerez la capacite d'exprimer I'imbrication de differents nceuds (depuis UML 2.0), uti- 
lises ici pour montrer ce qui est deploye en DMZ. 

• En rapprochement avec la configuration materielle : 

• les environnements de travail « Comptable » et « Logistique » sont chacun deployes sur un 
des PC centraux - I'environnement comptable correspond au deploiement de I'lHM de SAP 
R3 sur poste client lourd ; 

• les environnements de travail « Receptionniste » et « Repartiteur » sont mis en oeuvre sur 
des PC agence - au travers d'un portail le receptionniste accede a la fois a des fonctions 
propres a SIVEx et aux IHM de SIEBEL ; 

• L'environnement de travail « Operateur de quai » est implante sur un PC agence specifique 
qui devra etre muni d'un lecteur de codes-barres et d'une balance de pesee ; 

• L'environnement de travail « Chauffeur » est deploye sur un terminal specifique en termes de 
materiel, mais prenant en charge I'execution d'une machine virtuelle Java. 
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Figure 10-3 : Modele de deploiement SIVEx 



Developpement du modele d'exploitation 

L' elaboration d'une architecture d'exploitation a deja commence en concep- 
tion generique. A partir du deploiement, il est possible de la completer en 
fonction des machines et des postes de travail, tout en integrant les besoins 
exprimes en analyse. Conformement a ce qui vous a ete explique en concep- 
tion generique, le modele d'exploitation va definir les applications installees 
sur les postes de travail, les composants metier deployes sur les serveurs et les 
instances de bases de donnees implantees sur les serveurs egalement. 

Les applications se determinent par regroupement des fonctions de l'utilisa- 
teur, tout en respectant la definition des postes de travail. On partira du modele 
de specification fonctionnelle pour definir les applications du systeme - a 
cette occasion, les choix d'utilisation de progiciels du marche et 1' anticipation 
des impacts sur F architecture pourront etre affines. Un decoupage ideal en cas 
d'utilisation permet en effet d'affecter une application a la realisation d'un 
nombre entier de ces derniers. II faut cependant tenir compte des regroupe- 
ments qu'a pu realiser l'analyste, car un cas d'utilisation peut concerner 
plusieurs acteurs differents sur des postes de travail separes. On rencontre 
done les cas de figure suivants : 
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un meme cas d' utilisation donne lieu a plusieurs applications. Cette situa- 
tion survient lorsque plusieurs acteurs y participent simultanement ou au 
travers de postes de travail differents ou encore par la reutilisation des 
fonctions d'un progiciel ; 

un ou plusieurs cas d'utilisation recourent a la meme application. C'est un 
choix d'ergonomie du poste de travail, lorsque les cas d'utilisation concer- 
nent le meme acteur. 



ETUDE DE CAS : DEFINITION DES APPLICATIONS 

L'exemple ci-apres illustre la realisation des cas d'utilisation par des applications, a partir d'un 
extrait du modele de specification fonctionnelle. 

Nous avons attribue un nom a chaque application de SIVEx. L'application ConVEx servira aux 
exemples de conception preliminaire et detaillee. Elle correspond aux fonctions de planification 
et de controle des missions. 

• ConVEx implemente tout ou partie des cas d'utilisation Gestion de mission et Suivi de mis- 
sion ; 

• ConVEx est destinee au poste de travail du repartiteur. 



ComptaYEx : 

Knvironnement 
de travail du 
comptablc avcc 
SAP 

TransVEx : 

Transmission et 
synchronisation des 
donnees enlre sous- 
systemes (EAI) 




ConVEx : 
Environnement 
de travail du 
repartiteur. 
(gestion du 
con voyage) 



Gestion des missions 



. o 

Plannification des missions 




"■-ik-SuiVEx : 



Gestion du 
chauffeur 



ComVEx : 
Environnement 
commercial du 
receptionniste 
avec SIEBEL 



CttVEx : 
Consultation 
du client 



Figure 10-4 : Identification des applications du systeme SIVEx 
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Poste Comptable 



e<Application» S I 
ComptaVex 
SAP R3 client 



Poste Repartiteur 



s<Application» 
ConVex.exe 



Poste Receptionniste 



«Application» 
Internet Explorer 



□ 



□ 



Figure 10-5 : Definition des applications dans le modele d 'exploitation 



La distribution d'un composant facilite sa reutilisation, puisque les memes 
services sont accessibles depuis differentes applications. La premiere facon 
d'identifier les composants distribues consiste done a recenser les categories 
d' analyse partagees par plusieurs applications. Le critere de partage et de 
reutilisation n'est a posteriori pas suffisant : les composants distribues offrent 
en effet un decouplage logiciel entre les applications et le metier. Ce decou- 
plage facilite la reutilisation, mais egalement la maintenance et revolution du 
systeme global. Nous conseillons done de transformer chaque categorie 
d' analyse en composant d' exploitation, des lors que celle-ci represente des 
concepts du domaine. Larchitecte logiciel peut ensuite arranger ce decoupage 
pour integrer des criteres de conception. Dans la perspective d' optimisation 
du systeme, il peut etre en effet judicieux de regrouper au contraire plusieurs 
categories d' analyse dans le meme composant. 



L introduction de progiciels dans le systeme est une forme de reutilisation qui 
bouleverse notre approche d' architecture orientee objet. En effet, le progiciel 
introduit a la fois des concepts fonctionnels parfois orthogonaux a 1' analyse 
effectuee et des contraintes techniques d'interoperabilite. Dans ce cadre, nous 
allons bien entendu proceder a F assimilation du progiciel a un composant 
supplementaire de Farchitecture logicielle. Pour couvrir Fensemble de la 
problematique d'integration, nous rattachons cependant notre methode aux 
techniques d'analyse et de conception employees dans le domaine de l'EAI. 
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Pour completer la definition des composants, il est ensuite necessaire d'en 
enumerer les interfaces. II s'agit d'un travail d'approche consistant a produire 
une description sommaire de ce que realise un composant dans le systeme. Le 
premier objectif de ces interfaces vise a donner a Fingenieur d' exploitation une 
vision fonctionnelle de ce que realisent les differents composants afin de lui 
permettre d'ameliorer son diagnostic de pannes. Les interfaces servent egale- 
ment a preciser les dependances logicielles qui vont s'etablir entre composants. 
Notez bien que nous sommes encore loin de definir des operations et des signa- 
tures precises. Dans le cadre de notre processus a precision croissante, c'est 
seulement en conception detaillee que Ton aboutira a ce resultat. 

Des interfaces particulieres sont egalement definies pour permettre l'encapsu- 
lation des progiciels en composants logiciels. Techniquement, ces interfaces 
correspondent soit a des fonctions distributes synchrones qui s'apparentent 
aux operations EJB que Ton desire mettre en ceuvre dans notre architecture, 
soit a des messages de donnees transmis de maniere asynchrone. Dans tous les 
cas, les techniques d'interoperabilite proposees par les editeurs de progiciels 
sont plus assimilables a des flux de synchronisation de donnees qu'a des 
services proprement encapsules. Dans le cadre de notre architecture orientee 
objet, une interface de progiciel, que Ton nomme « interface EAI » tout au 
long de cet ouvrage, represente des flux de synchronisations d'objets. 



ETUDE DE CAS : DEFINITION DES COMPOSANTS METIER 

Pour SIVEx, toutes les categories donnent lieu a un composant distribue, sauf la categorie Trans- 
mission comptable car elle ne decrit pas proprement de nouveaux objets metier mais corres- 
pond exclusivement a des concepts applicatifs d'echanges de donnees. 

D'autre part, le couplage des concepts entre les categories Reseau et Ressource a pousse le 
concepteur a les regrouper dans un meme composant distribue. Le diagramme ci-dessous i I lus- 
tre I'identification des composants sur la base du modele structurel d'analyse. 
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«category» 






Mission 







«category» 
Transmission 
Comptable 



1 








«categoiy» 






PlanTransport 




1 \ 


N 



«category» 
Commande 



/ 
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«category» 






Fa ctu ration 













«category» ^T' 
Roseau 



«category>> £~ 
Ressource 



«category>> 
Colis 



«category» 
Client 



«category» 
Exploitation 
Informatique 



Figure 10-6 : Identification des composants metier du systeme SIVEx 

Tous les composants identifies sont ajoutes, avec leurs dependances, au modele d'exploitation. 



«EJB» 
Mission 



— 7 * — 

/ \ 

/ \ 



«EJB>> 

93 

PlanTransport 



93 



«EJB» 5 I 
Factu ration 



«EJB» H I 
Commande 



:<EJB» S I 
Colis 



«EJB» 




Client 





«ejb» sm 

Ressource 
Reseau 



«EJB» 9Zl 
-*>\ Exploitation 
informatique 



Figure 10-7 : Schema de dependances entre composants metier du modele d'exploitation 

Dans un second temps, les interfaces sont definies en termes de regroupement de responsabili- 
tes. Conformement a ce que nous avons deja mentionne, il s'agit juste de preciser un premier 
niveau de definition qui devra etre affine en conception detaillee. Le tableau ci-dessous illustre 
cette premiere ebauche de definitions pour les interfaces des composants Commande et 
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Mission. Vous remarquerez que, par convention, tous les noms d'interfaces sont precedes d'un I, 
comme suggere dans [UML-UG 99]. 



Composant 
di^tribup 


Interface 


Description de ses responsabilites 


Mission 


IMission 


Gestion distribuee d'une entite mission : 
creation, modification, validation, archivage. 


ISuiviMission 


Distribution des informations d'une mission en execution. 
Notification d'alertes, calcul des durees estimees de par- 
cours, rafraichissement des informations d'avancement. 
Distribution automatique des informations pour le rafrai- 
chissement des en-cours de commandes. 


Commande 


ICommande 


Gestion distribuee des entiles commande. 

Creation, modification, validation, annulation, archivage 

et suppression d'une commande. 


EnCoursDeCmd 


Distribution des informations d'en-cours des commandes 
en execution. 

Reception des informations de mission, calcul des horai- 
res estimes de passage. 



Tableau 10-1 : Definition sommaire des interfaces metier 



Pour completer 1' architecture logicielle, il reste a identifier et definir les inter- 
faces EAI afin de preparer leur rattachement aux concepts orientes objet de 
notre processus de developpement. Nous verrons par la suite les avantages a 
appliquer une methode orientee objet a un domaine du logiciel, l'integration 
des progiciels d'entreprise, dans lequel une approche purement fonctionnelle 
est generalement employee. 



ETUDE DE CAS : DEFINITION DES INTERFACES EAI 

Cette definition consiste a recenser dans un premier temps les objets metier de SIVEx et a les 
projeter sur chacun des composants du systeme : SAP R/3, Siebel, Mission, Commande, Factu- 
ration, etc. Dans un second temps, chacune des intersections du tableau est renseignee avec 
les operations de synchronisation que realisent les composants. 
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Composant 


CAD DO 

oAr no 


biebel 


Client 


Mission 


Client 


Consultation 
Renseignement 
des donnees 
comptables 
Interdiction de vente 


Consultation Ren- 
seignement des 
donnees 
commerciales 


Consultation 
Suppression 
Archivage 


Consultation Ren- 
seignement des 
adresses de 
livraison 


Commande 


Consultation Conso- 
lidation 


Creation Consul- 
tation Modifica- 
tion des 
conditions com- 
merciales, 
Suppression 




Consultation Ren- 
seignement des 
en-cours 



Tableau 10-2 : Identification des interfaces EAI 



Pour chaque case renseignee de cette matrice, une ou plusieurs interfaces EAI sont identifia- 
bles. Par exemple, I'interdiction de vente d'un client donne lieu a une interface EAI entre les com- 
posants SAP R3 et Siebel. Dans I'optique d'en donner une premiere definition, nous nous 
sommes inspires des PIPs (Partner Interface Processes) du consortium RosettaNet (www.roset- 
tanet.org) charge de definir des standards d'interfaces d'echanges pour I'industrie electronique. 

Chaque PIP constitue effectivement une specification d'interface, dont la modelisation UML est 
compatible avec le profil « UML for EAI », propose par I'OMG en janvier 2002. 

Dans ce cadre, une specification metier de I'interface utilise un diagramme d'activite pour 
decrire I'usage fonctionnel de I'interface EAI. 



T v 

(Interdire client a X ^ 
la vente J 



Client 



{ blocage = true } 



^ Bloquer client 



If 



(Mettre a jour X 
client J 



Figure 10-8 : Schema de specification metier d'une interface EAI 



Par la suite, un diagramme de sequence concerne I'analyse du protocole realisant la synchroni- 
sation d'information. Remarquez la notation des messages asynchrones utilises par les 
mecanismes EAI de SIVEx, ainsi que la numerotation decimale des messages. 
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1 


1 1 


=1 


SAP R3 




EAI 




SIEBEL 




Client 



i 1 ! «notification» 1 client inferdireVente 
>T1 



1 1 client bloquerCompte 



1.2 client mettreAjojr 



^0 



«return» 1.2J1 client estSynchronise 



Figure 10-9 : Analyse du protocole d'une interface EAI 



Dans le cadre d'une architecture 3-tiers : application, composant distribue, 
stockage des donnees, il reste maintenant a identifier les instances de base de 
donnees pour optimiser la distribution du systeme. Ces dernieres se definis- 
sent en fonction de criteres de repartition de donnees soit pour accelerer les 
temps d'acces, soit pour integrer d'autres systemes, soit pour isoler une partie 
du systeme en vue de sa reutilisation. 



ETUDE DE CAS : DEFINITION DES INSTANCES DE BASE DE DONNEES 

Dans le cadre de SIVEx, I'optimisation des temps d'acces est geree par les mecanismes de la 
couche d'acces aux donnees et ne necessitent pas une separation en plusieurs instances. 
Seules les donnees de la categorie Client doivent etre isolees en vue de leur reutilisation au sein 
du systeme d'entreprise. Nous disposerons done de deux instances de base de donnees : les 
donnees SIVEx et une base Clients. 

II reste a repartir les donnees entre agences et siege. La base Clients doit rester unique car e'est 
le meilleur moyen de garantir la coherence de ce referentiel metier. De plus, la frequence de mise 
a jour des clients depuis les agences est relativement faible et permet de conserver ces informa- 
tions au niveau central. En revanche, les donnees traitees en agence et en central n'etant pas les 
memes, il semble naturel que leurs schemas soient differents, suivant qu'il s'agit d'une agence 
ou du central. Une frequence de mise a jour egalement differente fait pencher la balance en 
faveur d'une conception des bases separees en deux types d'instances : Agence et Central. 
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«DB instance» 


3D 


Base SIVEx 


Agence 





«DB instance» 




Base SIVEx 


Central 





<DB instance» § 
Base Clients 



F/'gure f 0-f 0 : Modele d 'exploitation des instances de base de donnees 



c 

Conseil 



CONSOLIDEZ LE MODELE D'EXPLOITATION POUR CHAQUE APPLICATION 

Une fois les composants d' exploitation identifies - applications, composants 
distribues et instances de bases de donnees - avec leurs interfaces metier et 
EAI definies, il convient de tracer un diagramme des dependances du point 
de vue de chacune des applications du systeme. Vous verrez alors se dessiner 
le role de chaque interface par rapport aux applications, les roles que jouent 
les composants entre eux et les contextes d'acces aux instances de base de 
donnees. 

Ces diagrammes vont vous permettre de consolider les definitions du modele 
d' exploitation et de cartographier les flux de donnees distributes qui utilisent 
le reseau. 



ETUDE DE CAS : CONSOLIDATION DE L" APPLICATION CONVEX 

Le modele d'exploitation permet de tracer sur plusieurs diagrammes les dependances entre les 
composants. La figure suivante livre un apercu des composants impliques par I'application 
ConVEx. 
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ISuiviMission 






«EJB» 






Ressource 




Reseau 




IRessource 







o 



«EJB» £ | 
Commande 
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«DB lnstance» S | 
Base SIVEx 
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Client 



«DB lnstance» S | 
Base Clients 



Figure 10-11 : Diagramme de consolidation de /'application ConVEx 



Pour terminer le paragraphe sur le modele d' exploitation, il convient de ne pas 
oublier le travail commence en conception generique. En effet, le modele 
d' exploitation comporte deja les instances de base de donnees et les compo- 
sants offrant les services techniques transverses. Ces composants restent 
evidemment sous-jacents au travail de definition que nous venons d'effectuer. 
lis definissent des protocoles et des interfaces implicitement accessibles par 
tous les composants d' exploitation du systeme. Vouloir les integrer dans un 
travail de consolidation aurait complexifie les ramifications des dependances 
sans apporter de progres aux elements de notre conception. 

Enumeration des interfaces utilisateur 

Si les composants communiquent par le biais de leurs interfaces, les applica- 
tions, quant a elles, sont utilisables par le biais de leurs interfaces utilisateur 
ou IHM (Interface Homme Machine). Afin de completer 1' architecture 
d' exploitation, les concepteurs peuvent dresser la liste des vues d'lHM dont 
dispose chaque application. II n'y a ici aucune technique propre a UML : une 
liste des vues attendues et de leurs principales fonctions suffit a ce niveau de 
description. En outre, ces definitions servent a identifier des composants 
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d'lHM transverses aux applications, augmentant ainsi la reutilisation dans la 
conception de la couche de presentation. 

^ EXPLOITEZ LES DEFINITIONS D'lHM TOUT AU LONG DU PROCESSUS 2 TUP 

Dans le cadre d'entreprises dont la culture de specification est fortement 
axee sur la definition d'ecrans, il est fort judicieux d'accompagner le deve- 
loppement 2TUP de la definition des IHM. 

A l'etape de capture des besoins fonctionnels, ceux d'lHM peuvent se 
transformer en maquettes pour chaque cas d'utilisation. Leur presenta- 
tion aux utilisateurs pourra susciter des remarques et avoir des repercus- 
sions sur les regies de gestion metier. 

A l'etape d' analyse, au niveau de F analyse de 1' application plus particu- 
lierement, les messages produits ou recus par les acteurs peuvent etre 
attaches aux vues deja definies. Cette pratique permettra de mieux fixer 
le role fonctionnel de chaque vue et d'ameliorer eventuellement leur 
ergonomie. 

A l'etape de conception preliminaire, les vues de la maquette sont for- 
malisees et reparties sur les differentes applications du modele d'exploi- 
tation. L'identification des composants d'lHM et la reutilisation au 
niveau de la couche de presentation s'en trouveront affinees. Leur 
presentation aupres des utilisateurs permettra enfin d'ameliorer 1' ergo- 
nomie de fonctionnement. 

Bien que l'ecran constitue un excellent support de communication avec les 
utilisateurs, a exploiter tout au long du processus, nous ne sommes pas ici les 
promoteurs d'une methode pilotee par les ecrans, car inversement, le proces- 
sus 2TUP prone un developpement axe sur la definition du metier. II ne faut 
done pas confondre succession d'ecrans avec processus d'entreprise, ni 
ergonomie avec plus-value metier. 



ETUDE DE CAS 

CONVEX 



ENUMERATION DES VUES DE ^APPLICATION 



Cette enumeration definit les interfaces exploiters par I'application de gestion du convoyage 
(missions) et donne une idee plus precise de I'environnement de travail du repartiteur. 



Vue d'lHM 


Description 


Selection mission 


Selection d'une mission dans une liste filtree et triee des missions 
de I'agence courante. Les criteres sont les suivants : affectation, 
site, client, poids, chauffeur, vehicule. 


Selection commande 


Selection d'une commande dans une liste filtree et triee des com- 
mandes presentes dans I'agence courante. Les criteres sont les 
suivants : affectation, site, client, poids, mission, quai. 
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Edition mission 


Feuille d'edition d'une mission. Creation, modification, suppression, 
validation et annulation. 


Tableau suivi de mis- 
sion 


Tableau de suivi des missions en cours d'une agence, affichage des 
retards, des evenements et des messages. 


Planning des ressour- 
ces 


Tableau de planning style GANTT d'affectation des chauffeurs et 
des vehicules aux missions. Cette vue se presente suivant deux 
options qui sont la matrice de planification des vehicules ou la 
matrice de planification des chauffeurs. 



Tableau 10-3 : Extraits des definitions d'lHM de /'application ConVEx 



L'enumeration des vues permettra de developper la structure des classes de la couche de pre- 
sentation. 



Developpement du modele logique 

Nous avons jusqu'ici defini les modeles de deploiement et d' exploitation en 
determinant les postes de travail et les composants de la solution visee. Nous 
devons cependant developper les classes necessaires au codage. Le modele 
logique est precisement celui de la representation des classes organisees en cate- 
gories. Comme nous allons le voir, ce modele derive du modele structurel 
d' analyse d'une part et du modele logique de conception technique d' autre part. 

Une categorie de conception a des objectifs analogues a une categorie 
d'analyse : c'est un regroupement de classes a fort couplage. Les objectifs 
poursuivis ne sont cependant plus les memes ; les categories de conception 
organisent des classes techniques et contribuent a la reutilisation et a l'optimi- 
sation d'un systeme a developper. 

Les elements qui servent a identifier les categories de conception sont a la 
fois : 

les composants d' exploitation, qui definissent un ensemble coherent de 
classes a assembler ; 

les frameworks techniques, conservant la structure des couches logicielles, 
regroupent les classes travaillant dans le meme domaine de responsabilite 
technique et mettant en ceuvre les memes types de technologies ; 

les categories d'analyse qui structurent le metier en plusieurs domaines de 
specialisation logique et qui rassemblent des classes collaborant etroite- 
ment entre elles. 
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INFLUENCE DES COMPOSANTS D'EXPLOITATION 
SUR L'ORSANISATION DU MODELE LOGIQUE 



Premierement, les composants d' exploitation peuvent constituer autant de 
sous-projets dans le developpement global du systeme. On pourrait des a 
present decouper le developpement global de SIVEx en differents sous- 
projets et chaque equipe se verrait confier la tache de concevoir des applica- 
tions et des composants distribues. Dans ce cadre, chaque equipe en charge 
de sa conception pourra developper des categories de classes paralleles et 
independantes les unes des autres. 

Deuxiemement, une categorie de conception ne peut regrouper des classes 
destinees a fonctionner pour moitie sur une application et pour moitie sur un 
composant distribue : il faut choisir, ou l'une ou l'autre. Un composant 
d' exploitation est en effet realise par un nombre entier de categories de con- 
ception. Cela n'exclut pas pour autant qu'une meme categorie puisse partici- 
per a l'elaboration de plusieurs composants par reutilisation. 

Retenez done que le modele d' exploitation guide l'organisation du projet au 
travers de son modele logique, car une meme categorie de conception ne 
peut etre decoupee entre les realisations de differents composants. 



® 

Etude 



INFLUENCE DES FRAMEWORKS TECHNIQUES 
SUR L'ARCHITECTURE LOGIQUE DE CONCEPTION 

Rappelons que les frameworks techniques peuvent etre abstraits. Nous effec- 
tuons par exemple une distinction entre : 

le framework de journalisation auquel correspond un composant 
d' exploitation reutilisable ; 

et le noyau applicatif ou la definition d'un mecanisme modele vue con- 
troleur (MVC) qui apporte une structure de conception generique, mais 
qui necessite des complements de code. 

Les frameworks concrets font deja l'objet de categories dans le modele logi- 
que de conception technique. Ces categories continuent d'exister dans la 
nouvelle organisation pour fournir leurs services techniques. 

Les frameworks abstraits vont permettre d' organiser les categories de concep- 
tion. Chacun d'eux correspond generalement a une couche logicielle du systeme. 
Dans cette optique, nous organisons le modele logique suivant les cinq couches : 
Presentation, Application, Metier, Acces aux donnees et Stockage de donnees. 

A chacune des couches correspond un package qui englobe les categories de 
conception. Si on leur applique les regies de nommage UML, on distingue 
alors la categorie Metier: .-Mission de la categorie Acces aux donnees:: 



Chapitre 10 • Conception preliminaire 



251 



Mission. La figure 10-10 illustre F organisation en couches des categories de 
conception. 



Stockage donnees 



1 



«category>> 
Mission 



i 



Acces donnees 

1 1 


«category» 
Mission 





Application 



«category» 
Mission 



Metier 



«category» 
Mission 



I Presentation 



■=<category> 



Figure 10-12 : Projection de la categorie «Mission» surles couches logicielles 

Par definition, la couche metier est implicitement structuree suivant les cate- 
gories d'analyse. Afin de formaliser l'influence des frameworks abstraits sta- 
le decoupage en categories de conception, la figure 10-13 illustre la realisa- 
tion concrete du framework noyau metier, suivant les domaines metier definis 
par F analyse. 



«technical framework» 
Noyau Metier 



«category» 
Commande 



<<category>> 
Client 



«category>> 
Ressource 



«category>> 
Mission 



«category» 
Reseau 



Figure 10-13: Relations entre categories dans le package Metier 
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Chaque categorie de ce schema correspond a l'une des categories de concep- 
tion qui realisent la couche metier. La relation de generalisation entre 
packages UML est moins formelle que celle entre classes ; elle signifie 
simplement que le contenu d'un package est la specialisation d'un super- 
package. Considerees de l'exterieur des packages, les definitions publiques du 
super-package, principalement ses interfaces, sont heritees par specialisation. 
Ainsi, la categorie Metier: -.Client en tant que specialisation du framework 
Noyau Metier herite de comportements techniques homogenes et repandus a 
toutes les autres categories de la couche Metier. C'est ainsi que nous appli- 
quons les informations issues de F analyse objet, en projetant les categories 
d' analyse sur les couches logicielles. 




TECHNIQUE D'ORSANISATTON DU MODELE LOSIQUE 
DE CONCEPTION SYSTEME 



On rappelle que la conception systeme est le niveau d' abstraction vise par 
l'etape de conception preliminaire. Pour obtenir le decoupage en categories 
de conception, notre approche consiste a prendre tour a tour chaque compo- 
sant d' exploitation et a considerer le devenir de chaque categorie d' analyse 
par rapport aux frameworks techniques abstraits. C'est ce que nous avons 
realise pour F etude de cas. 

A l'echelle d'un systeme tel que SIVEx, cette technique fait apparaitre des 
redondances entre les differentes categories. Ces redondances conduisent a 
identifier les parties reutilisables que Ton isolera dans des categories specif! - 
ques pour en faciliter la reutilisation. 



ETUDE DE CAS : ORGANISATION DU MODELE LOSIQUE 

Le decoupage presente ici correspond a la fagon dont les concepteurs envisagent d'organiser 
leur conception. Notez qu'il ne s'agit pas de la seule et bonne organisation car nous sommes ici 
dans le domaine subjectif des choix de conception. 

Decoupage pour I'application ConVEx : 

En tant qu'application, ConVEx n'est concernee que par les frameworks issus des couches de 
presentation et d'application. Dans le tableau 10-3, chacune des cases remplies correspond a 
une categorie de conception, qui definit brievement le role qu'elle doit occuper au sein du sys- 
teme. 



Categorie 


Noyau presentation 


Noyau applicatif 


Mission 


Gestion de mission 


Mission et Suivi de missions 


Tableau de suivi de mission 


Commande 


Consultation des commandes* 


Selection des commandes 


Ressource 


Consultation des ressources* 


Selection des ressources 
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Reseau 


Gestion des mises a disposition 


Mise a disposition des ressour- 
ces 


Consultation des sites et des par- 
cours* 


Selection des sites et des par- 
cours 


Exploitation informatique 




Gestion des habilitations 



Tableau 10-4 : Projection des categories d'analyse dans le cadre de /'application ConVEx 

Les categories marquees d'un asterisque represented des mecanismes reutilisables dans 
d'autres contextes applicatifs. Ainsi, le concepteur a interet a isoler ces mecanismes dans des 
categories separees, de maniere a en favoriser la reutilisation. 



Decoupage pour le composant metier Mission : 



Le composant Mission implements son propre noyau metier et s'appuie egalement sur la couche 
d'acces aux donnees qui lui est propre. En regie generale, la trame des categories identifiee en 
analyse est similaire a celle de la couche metier en conception. 



Framework / Categorie 


Noyau metier 


Acces aux donnees 


Mission 


Implementation des interfaces 
IMission et ISuiviMission. 


Acces aux informations des 
missions 


Commande 


Utilisation de I'interface ICom- 
mande 




Plan Transport 


Utilisation de I'interface IPIan- 
Transport 




Ressource 


Utilisation de I'interface IRes- 
source 




Reseau 


Utilisation de I'interface IReseau 




Exploitation informatique 


Utilisation de I'interface IHabilita- 
tion 





Tableau 10-5 : Projection des categories d'analyse dans le cadre du composant metier 

Mission 



Les categories resultantes pour la couche presentation s'etablissent en fonction des besoins 
afferents des differentes applications. Les dependances entre categories pourront etre ensuite 
definies en fonction des structures des differentes IHM congues. Ainsi, on distingue une catego- 
rie Mission d'une categorie SuiviMission car les besoins de presentation seront differents. On dif- 
ferencie egalement EnCoursCommande de EnCoursCommandeWeb car les techniques 
employees seront cette fois-ci differentes. 

Notez que les categories de la couche Application seront identiques. II existe en effet un fort cou- 
plage entre I'application et sa presentation, qui correspond au couplage existant entre la vue et 
le controleur du modele MVC. 

Les categories resultantes pour la couche metier refletent le modele structurel d'analyse, d'ou 
sont absents les concepts purement applicatifs. Dans I'exemple de SIVEx, I'analyste a deja isole 
dans la categorie Transmission Comptable des concepts propres a I'application ; cette categorie 
disparait de la couche metier. 
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«layer» 
Presentation 



«category» 
Comma nde 



«category» 
Client 



«category» 
PlanTransport 



«category>> 
Ressource 



«category» 
Facturation 



«category» 
Mission 



«category» 

EnCours 
CommandeWeb 



«category» 
RelanceClient 



«category» 
SuiviMission 



«category» 

Mise 
A Disposition 



«category» 
EnCours 
Comma nde 



<<category>> 
Reseau 



Figure 10-14 : Identification des categories de la couche Presentation 



«layer» 



«category» 
Pl»n Transport 



«category» 



«category» 
Client 



«category» 
Explatalioo 
Inrormalique 



Figure 10-15 : Identification des categories de la couche Metier 

Notez que les categories de la couche d'acces aux donnees seront egalement identiques. 
existe effectivement un couplage fort entre les concepts metier et leurs donnees 1 . 



1 .Couplage que le mecanisme de persistance EJB rend inutile de decrire dans le cas ou le concep- 
teur opte pour des composants geres par leur conteneur EJB (EJB CMP). 



Chapitre 10 • Conception preliminaire 



255 



Definir I'interface des categories 

Rappelons que chaque categorie regroupe des classes qui fournissent un 
ensemble coherent de services aux autres parties du logiciel. Comme nous 
vous l'avons deja signale, il est possible de considerer la categorie comme 
niveau d' encapsulation superieur aux classes, avec d'une part I'interface cons- 
titute des classes publiques et d'autre part F implementation comportant des 
classes privees. 

Dans un modele, I'interface d'une categorie se presente done sous la forme 
des classes et des interfaces utilisables de l'exterieur de la categorie. Nous 
avons introduit le stereotype interface qui, applique aux packages, isole ces 
definitions particulieres. 

Les interfaces des categories se construisent a partir des interfaces deja identi- 
fiees des composants d' exploitation. Leur definition necessite cependant 
d'etre precisee et doit prendre en compte les operations identifiees dans le 
modele d'analyse. Ces operations se repartissent sur les couches application, 
metier ou acces aux donnees en fonction de leur specialite. D' autres opera- 
tions d'analyse correspondent plutot a des mecanismes internes a la categorie 
et ne se positionneront pas dans une interface. Le tableau suivant vous donne 
un exemple de repartition des operations d'analyse. 



Operation 
d'analyse 


Description 


Positionnement 


Affecter commande 


Associer une commande a une mis- 
sion, ce qui declenche la verification 
de la charge du vehicule et la 
creation d'une etape, s'il s'agit 
d'une mission de tournee. 


C'est un service metier de la cate- 
gorie Mission qui entre dans la 
definition de I'interface Mission. 


Verifier tonnage 


Operation declenchee par I'ajout 
d'une commande. 


C'est une operation metier exclusi- 
vement declenchee par I'ajout 
d'une commande. II s'agit done 
d'une operation interne a la 
categorie Metier::Mission. 


Editer bordereau 
etape 


Operation declenchee a la 
validation d'une mission. 


C'est d'une part une operation qui 
gere un aspect applicatif. D'autre 
part, puisqu'on desire localiser 
cette operation sur le poste client il 
s'agit egalement d'un service de 
Application::Mission. 



Tableau 10-6 : Exemple de positionnement des operations d'analyse 



Outre la prise en compte des operations d'analyse, les frameworks techniques 
definissent eux-memes des interfaces identifiees lors de la conception gene- 
rique. Celles-ci vont evidemment influencer F identification et la structure des 
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interfaces des categories de conception. En partant de la conception generique 
des couches Presentation et Metier, nous allons illustrer comment apparaissent 
les interfaces des categories de conception. 

II nous parait cependant essentiel d'introduire auparavant la definition d'un 
design pattern connu, parce qu'il formalise le concept d'interface entre cate- 
gories. 

A LE DESIGN PA TTERN « FAQ ADE » 

Le design pattern « Facade » [Gamma 95] constitue une technique comple- 
mentaire pour organiser le modele logique. Une facade a pour fonction de 
produire une classe qui constitue le seul point d' entree aux services offerts 
par la categoric L'objectif de cette classe est de mieux controler les echan- 
ges d'une categorie avec le reste du systeme et de faciliter le bon usage 
d'une categorie. 

La realisation d'une facade consiste en la definition d'une classe dont les 
operations reproduisent les services offerts par l'ensemble d'une categorie. De 
maniere a apporter plus de coherence par rapport aux interfaces identifiees, on 
va developper une facade par interface de la categorie. L utilisation d'une ou 
de plusieurs facades par categorie simplifie la comprehension des objectifs 
que realisent les classes de cette categorie. La figure suivante montre la facade 
de la categorie Metier: .-Mission qui realise l'interface IMission. 



<<categoty>> 
Mission 



J. 



MtssionDeTournee 



MIsstonTr action 



EvenementMission 



<-\ 



Etape 

iT 



IncidentMission 



J. 



IncidentEtape 



Fcade de la categorie 
Metier:Mission 



«facade» 
IMissionlmp 



<<interface>> 
IMission 



"5" 



creerTournee() 

creerTraction() 

affe cte rC om ma nde( ) 

affecterChauffeurO 

atfecterVehiculeO 

valider() 

invalider() 

signalerDepartO 

completefTrajetO 

desaff ecte rRessou rces() 

desa ff ecte rCom ma nde( } 



Figure 10-16: Structure d'une fagade pour la categorie Metier: Mission 

La fa9ade masque au code client la complexite interne de la categorie qu'il 
utilise. Elle reduit le nombre de classes publiques et favorise une utilisation 
correcte des services offerts. Elle permet egalement de formaliser la 
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dependance entre categories et minimise les couplages entre composants. En 
d'autres termes, la facade contribue a transformer les categories en modules 
reutilisables et aide a mettre en ceuvre le leitmotiv « reutiliser pour concevoir 
et concevoir pour reutiliser », expose au chapitre 9. En consequence, le 
concept de facade correspond exactement aux principes que nous cherchons a 
instaurer pour developper un modele logique de conception, a la fois robuste 
et evolutif. 

UTILISEZ DES FACADES POUR CONCEVOIR LES COMPOSANTS DISTRIBUES 

Lorsque Ton utilise un middleware de distribution tel que WebServices, 
EJB, .Net, Corba, DCOM ou RMI, il est indispensable de reduire le nombre 
d'interfaces [Orfali 98] en identifiant des facades sur les couches concernees 
par la distribution. Cela reduit en consequence le nombre de references 
d'objets distribues et ameliore sensiblement les performances de l'infras- 
tructure de distribution. 



ETUDE DE CAS : DEVELOPPEMENT DES INTERFACES ET DES FACADES 

Nous allons passer en revue tour a tour les interfaces d'un framework technique, une categorie 
de la couche d'application et une categorie metier. 

Interface du frame work technique Noyau applicant: 

Le Noyau applicatif est issu de la conception generique. II est caique sur la classe Documentet 
les interfaces CommandeApp et Vue. 

La classe Vue represente toutes les fenetres d'un IHM qui seront porteuses conformations prove- 
nant d'un ou de plusieurs objets du modele. 

La classe Document represente les entites qu'un utilisateur manipule au travers d'une ou de plu- 
sieurs vues. Le document constitue le cache des informations presentees dans une vue. Au sein 
d'une application, il joue generalement le role de conteneur des donnees necessaires aux fonc- 
tions CRUD (Create, Retrieve, Update, Delete) d'un objet metier, ou le role de graphe d'objets 
permettant d'agir sur des relations entre objets metiers, ou encore celui d'ensemble d'objets 
metier de meme type pour les recherches et la definition de listes. Ce concept est associe au 
design pattern Observateur qui vous sera presente au chapitre 1 1 . 

La classe CommandeApp (commande applicative) represente les processus de I'application. Ce 
sont toutes les executions declenchees par un utilisateur depuis une vue. Ce concept est asso- 
cie au design pattern Commande qui vous sera egalement presente au chapitre 1 1 . 

Linterface du framework technique est done composee des trois classes representees a la figure 
suivante. 




Conseil 
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Document 



synchroniser!) boolean 
sauvegarder() : boolean 



<<lnterface» 
Noyau Applicatif 



<<lnterface» 
Vue 



ouvnrQ 
fermer() 



«-;lnterface» 
CommandeApp 



executer() 



Figure 10-17 : Interface du noyau applicatif 
Les classes publiques de la categorie Application-Mission : 



II y aura autant de classes publiques qu'il y a de documents et de commandes applicatives, les 
panneaux d'lHM correspondant aux vues appartiennent quant a eux a la couche de presenta- 
tion. Le diagramme ci-apres represente les documents utilises par I'utilisateur, dont les deux 
plannings d'affichage possibles : le planning d'affectation des chauffeurs correle avec le celui 
des vehicules. 



Document 



«lnterface» 
Mission 



DocMission 



DocPlanning 



DocPlannmgChauffeur 


equivauta 


DocPlanningVehicule 


0 1 0.1 



Figure 10-18: Interface des documents de la categorie Application::Mission 

Les commandes applicatives sont de deux ordres : celles issues d'une action portant sur une 
classe de la couche metier, et celles qui n'ont qu'une portee applicative. Les premieres provien- 
nent d'operations deja identifies en analyse, ce sont par exemple toutes les operations d'affec- 
tation sur une mission. Les secondes peuvent resulter soit de identification des besoins d'lHM, 
soit de I'analyse de Implication ; il s'agit par exemple des operations de selection, de recherche 
ou d'impression. 
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«lnterface» 
Mission 



«lntefface» 
CommandeApp 



Commandes 
metier 



5 



CmdAffectatranRessource 



CmdValidation 



CmdAffectationCommande 



«lnterface» 
CommandeApp 



C o m ma-des 

appiicatrves 



3 



CmdSelectionMission 



Cmd Ed ition Mission 



CmdOuvnrPlanning 



Figure 10-19 : Interface des commandes de la categorie Application::Mission 
Interface de la categorie Metier.Mssion : 



Les facades de cette categorie sont identifies a partir des operations que le composant metier 
doit mettre a la disposition des applications. Conformement aux interfaces deja identifies sur le 
composant distribue Mission, nous developpons les deux fagades Mission et ISuiviMission. 
Encore une fois, il faut tenir compte ici du framework technique Noyau Metier. Ce dernier caique 
sur le framework EJB definit I'interface, implementation et le gestionnaire (classe home) pour 
chacun des composants metier decrits par le mecanisme EJB. L'architecte logiciel a d'autre part 
congu pour chaque composant metier, une interface « criteres » representant les differentes 
fagons de retrouver, d'ordonner et de lister les objets metier en fonction de requetes qui ont ete 
predefinies par I'analyse des utilisations possibles du composant metier. Cette conception est 
expliquee plus en detail au chapitre 11. 



«lnterface» 
Noyau Metier 



«lnterface» 
IComposantMetier 

{EJB = entity CMP} 



«lnterface» 
ICriteresDuComposantMetier 
{EJB = session statefull} 



Figure 10-20 : Interface du framework technique Noyau Metier 



• Le composant metier realise un objet distribue associe directement a un objet d'analyse. On 
peut y recourir lorsque plusieurs applications doivent se synchroniser parallelement sur le 
meme objet. Le composant metier est done un EJB dans notre conception, comme e'est le 
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cas pour I'en-cours de commande qui est mis a jour par les processus d'acheminement des 
colis, tout en etant observe par les clients et les repartiteurs. 

Le gestionnaire du composant metier (classe home du mecanisme EJB), implicite par la 
declaration de la valeur etiquetee « EJB », pilote les cycles de vie des instances. C'est 
notamment a lui que s'adressent les applications pour controler la creation et la modification 
des objets. 

Les criteres du composant metier correspondent a des services utilitaires : echanger une 
reference d'objet metier par I'intermediaire d'une cle de reference metier ou exprimer un cri- 
tere de selection d'objets predefini par I'analyse des cas d'utilisation et de leurs besoins 
d'lHM. 

Les objets Mission et SuiviMission sont distribues suivant ce framework, comme I'illustre le 
diagramme ci-apres. La figure 10-21 schematise la structure de interface du package 
Metier::Mission et illustre la signification d'une generalisation entre une categorie metier et un 
framework abstrait provenant de la conception generique. 



1 



<<lnterface>> 
Noyau Metier 



«lnteriace» 
IComposantMetier 

{EJB = entity CMP} 



< 



«lnterface» 
ICriteresDuComposantMetier 
{EJB = session statefull} 



<<lnterface>> 
IM ission 



erTo 



e() 



creerT raction() 

a f fe c te rC o m m a n d e () 

affecterC hauffeur() 

affec terVeh iculef) 

validerO 

InvaliderO 

signalerDepart( ) 

com pleterT rajet{) 

desaffecterRessources() 

des affecterCom mandef) 



<<lnterface> 
Mission 



<<lnterface>> 
IS uiviM is sion 



CriteresM ission 



invallder() 

reordonnerEtapes() 
reestimer() 
arriveeEtape() 
departE tape() 
signalerA nom a lie () 
signalerP an ne{) 
fin M is sion() 



C riteresS u iviM is sion 



Figure 10-21 : interface de ia categorie Metier: Mission 

Le lecteur peut se demancler a juste titre, I'interet de concevoir le framework noyau metier, 
alors qu'EJB en soi represente deja une conception « prete-a-reutiliser ». Nous avons sou- 
vent ressenti le besoin d'aller un peu plus loin dans nos conceptions, en introduisant par 
exemple des mecanismes generalises pour lister les objets suivant des cles differentes, ou 
bien pour « reserver » I'objet a I'usage d'une session particuliere - creant ainsi un mecanisme 
de verrouillage metier au-dessus des simples mecanismes techniques fournis par les moni- 
teurs transactionnels et les bases de donnees. 
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«lnterface» 
Noyau Metier 



«lnterface» 
CntComposant 



reflnstance [*] :RemoteOID 



«remote» chargerEntite( sessionld : long, oid : OID = null) : EntComposant 
«remote» sauvegarder{ sessionld : long, entite : EntComposant) 
«remote» effacer( sessionld : long, oid : OID) 

«remote» lister( sessionld : long, cr : Critere) : Vector<EntComposant> 

«remote» activerlnstance( sessionld : long, oid : OID = null) : RemoteOID 
«remote» clore( sessionld : long) 



«lnterface» 




InstComposant {RMI} 




refSessionld [1 ..*] : long 
conteneur : URL 






«lnterface» 


o > 


EntComposant 


«remote» oid() : OID 


1 




A t 


«remote» reserver( sessionld : long) : boolean 




«remote» liberer( sessionld : long) 




«remote» desactiver( sessionld : long) 





A 



«lntertace» 
Mission 



«lntertace» 
InstSuiviMission 

{RMI) 



<$-i-- Lance ■ 



«lnterface>: 
CntMission 



(RMI) 



0..1 



EntSuiviMission 



gere 



EntMission 



Figure 10-22 : Interface de la categorie Metier:: Mission heritee du noyau metier 
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Concevoir la structure objet des IHM 

Nous sommes maintenant a un etat d' avancement oil la structure de la concep- 
tion est completement definie, ainsi que les interfaces qui permettent aux 
differentes categories de communiquer entre elles. Pour completer la vision du 
systeme, il est necessaire d'en concevoir les IHM. Leur conception ne fait pas 
specifiquement appel a des techniques UML, mais plutot a des regies d'ergo- 
nomie accompagnees d'outils de fabrication d'ecrans. 

La consequence notable est 1' apparition des classes correspondant aux vues 
panneaux ou pages d'lHM de la couche de presentation. D'une part ces 
panneaux contribuent a preciser F identification des documents et des 
commandes de F application, d' autre part on peut estimer que ces classes 
constituent en quelque sorte les interfaces des categories de la couche de 
presentation. 



Les panneaux de I'application ConVEx.exe - qui represents I'application cliente du repartiteur 
developpee en client lourd (Java Swing) pour des raisons d'ergonomie - correspondent aux clas- 
ses Documents identifies dans le package Application::Mission. Le framework technique Noyau 
Presentation consiste simplement a etablir le lien entre la classe JFrame de Java Swing et inter- 
face Vue necessaire au pilotage des applications. 



«lnterface» 
Noyau Applicatif 



«lnterface» 
Vue 



Java Swing 
JFrame 



Panneau 



Figure 10-23 : Definition de la classe technique Panneau (Java Swing) 

A chaque panneau identifie correspond une classe d'lHM. La conception detaillee des protoco- 
les entre I'application et I'utilisateur pourra ensuite etre formalisee par des diagrammes d'interac- 
tions UML (sequences ou collaborations) mettant en jeu I'acteur, le panneau, les commandes et 
les documents. 
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Panneau 



WMission 



WListeMission 



WPIanning 



WPIanningVehicule 



WPIanningChauffeur 



Figure 10-24 : Structure objet des panneaux de I'application ConVEx 

Dans le cas des postes de travail deployes en client leger, chaque page JSP represente une 
classe. En I'occurrence, ('utilisation de Struts necessite d'associer a chaque page une classe 
JavaBean. Le bean definissant exhaustivement I'ensemble des donnees echangees avec I'utili- 
sateur joue en fait le role de document vis-a-vis de notre conception. 



«lnterface» 
Noyau applicatif 



«lnterface» 
Vue 



Page JSP | ") 



Figure 10-25 : Definition de la classe technique Page JSP 



Organiser la configuration logicielle 

Le travail de conception preliminaire s'acheve par la definition des unites de 
fabrication du logiciel. II s'agit ici de consolider le modele logique avec les 
reutilisations de code detectees et de completer la configuration logicielle deja 
commencee en conception generique. 

A priori, chaque categorie se transforme en un sous-systeme de configuration 
logicielle. II faut cependant prendre en compte les parties a extraire pour 
beneficier de la reutilisation de code. Par exemple, le sous-systeme de presen- 
tation des commandes doit isoler specifiquement un sous-systeme regroupant 
les classes necessaires a la construction de la fenetre de recherche et de selec- 
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tion de commandes. Ce sous-systeme est en effet reutilise pour la presentation 
de F application ConVEx. 

Inversement, plusieurs categories peuvent etre regroupees dans le meme sous- 
systeme de configuration logicielle. Les couches presentation et application 
sont par exemple souvent indissociables et regroupees dans la meme unite de 
fabrication. C'est le cas des categories Presentation: .-Mission et Applica- 
tion: -.Mission qui participent a la definition d'un meme sous-systeme de cons- 
titution de l'application ConVEx. C'est seulement suite a la conception 
detaillee que chaque sous-systeme pourra etre precise avec les composants 
correspondants aux classes Java qu'il faudra coder. 



ETUDE DE CAS : ORGANISATION DE LA CONFIGURATION LOGICIELLE 

L'application ConVEx est elaboree a partir de deux sous-systemes de cons- 
truction du client ; l'environnement d'edition des missions et l'environnement 
de suivi des missions. Les deux sous-systemes correspondant aux panneaux 
de selection ont ete isoles afin de permettre leur reutilisation. Les sous- 
systemes issus de la conception generique sont integres. 
Cote serveur, il existe un sous-systeme de fabrication du composant distribue Mission ainsi, 
qu'un sous-systeme pour faeces aux donnees. Les deux sous-systemes sont separes par choix 
d'architecture technique. II est en effet necessaire de menager un serveur specifique gerant les 
connexions aux bases de donnees. 



1 



<< subsystem >> 
ConVEx Mission 



«subsystem» 
Selection 
Ressources 



1 



«subsystem» 
Selection 
Commande 



<<subsystem>> 
ConVEx Suivi 
Mission 



Ml 



i 



i 



<<subsystem» 
Noyau 
Applicatif 



«subsystem» 
Composant 
Mission 
1 



I 



«subsystem» 
Donnees Mission 



«subsystem» 
Distribution metiei 



Figure 10-26. : Organisation des sous-systemes de l'application ConVEx 
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Pour la suite, chacun des sous-systemes donne lieu a une subdivision en composants represen- 
tant I'implementation Java des classes de conception. 



Etude 



IL Y A COMPOSANT ET COMPOSANT ! 

Pour terminer ce chapitre, il nous semble necessaire de revenir sur la notion de 
composant et d'y apporter quelques precisions en matiere de terminologie. 

Un composant au sens d'UML represente un element physique a partir duquel 
on construit le logiciel. II peut s'agir d'un fichier de code tout comme d'un exe- 
cutable. Comme nous vous Favons explique, ce concept est trop vaste pour etre 
exploitable, et dans le cadre des projets, nous avons ete amenes a distinguer les 
composants d' exploitation des composants de la configuration logicielle. 

On parle egalement de composant pour la distribution. Dans ce cas, un com- 
posant distribue est un composant de la vue d' exploitation, au meme titre 
qu'une application ou qu'une instance de base de donnees. Le composant 
distribue participe au logiciel par l'ensemble des services accessibles via un 
middleware. Le composant distribue correspond done a une meme unite 
d' execution qui declare ses services par F intermediate de differentes inter- 
faces. Linterface d'un composant distribue ne doit pas etre confondue avec 
le stereotype interface d'UML qui correspond plutot a l'interface de Java. En 
conception preliminaire, l'interface du composant distribue est plutot une ou 
plusieurs categories qui permettent de declarer des services. En conception 
detaillee, les interfaces du composant distribue doivent ensuite coller a la 
notion d'interface EJB. 

On parle enfin de composant metier, ce qui integre une dimension fonction- 
nelle. II s'agit cette fois d'un composant de configuration logicielle qui 
regroupe les services issus d'une meme partie specifique d'un metier. Un 
composant metier s'identifie a l'aide des categories d'analyse et sert a reuti- 
liser les notions communes a plusieurs applications. Un objet metier corres- 
pond a une classe de F analyse du domaine et participe bien entendu a la 
realisation d'un composant metier. Un composant distribue peut regrouper 
plusieurs composants metiers. En les localisant sur le reseau, la distribution 
facilite la reutilisation des composants metier. 



Phases de realisation en 
conception preliminaire 

La conception preliminaire est avant tout affaire d'organisation ; il s'agit de 
preparer le modele de conception en integrant les resultats provenant a la fois 
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de Fanalyse et de la conception generique. Dans le cadre d'une application 
client/serveur, la conception du deploiement des postes de travail et des 
composants d' exploitation constitue un premier guide d' organisation. 

La vue d' exploitation est constituee d' applications, de composants distribues 
et d'instances de base de donnees necessaires au systeme. L' identification de 
ses interfaces precise la definition d'un composant distribue, tout comme les 
interfaces utilisateur precisent celle d'une application. Des interfaces EAI 
peuvent egalement etre definies lorsque Ton doit integrer des progiciels dans 
son systeme. 

Les categories de conception sont identifiees a partir des frameworks abstraits 
de la conception generique et des categories de 1' analyse. Une premiere liste 
des categories de conception fait apparaitre les elements communs que Ton 
isolera en vue d'une reutilisation. Chaque categorie doit ensuite definir son 
interface. Dans le cadre d'une distribution, le recours au design pattern 
Facade permet de reduire la multiplicite des interfaces et facilite le protocole 
d'utilisation du composant distribue. Pour les applications, il est utile de 
concevoir les IHM afin d' avoir une vision precise des interfaces des couches 
presentation et application. 

La conception preliminaire se termine en organisant la configuration logicielle 
du developpement. 

Le detail du processus suggere pour la conception preliminaire est le suivant : 

1 . Concevez le deploiement : 
identifiez les postes de travail ; 
deployez-les sur le reseau physique ; 

commentez et justifiez les caracteristiques operationnelles du deploie- 
ment : dimensionnement des reseaux, dispositifs physiques de securite, 
localisation des bases de donnees, etc. 

2 Elaborez le modele d' exploitation : 

identifiez les applications a partir des cas d'utilisation ; 

identifiez les composants distribues a partir des categories d' analyse ; 

ebauchez les interfaces des composants distribues ; 

identifiez et specifiez le cas echeant les interfaces EAI ; 

identifiez les instances de base de donnees afin d'optimiser la distribution ; 

enumerez les interfaces utilisateurs des applications ; 

completez la vue d' exploitation. 

3. Organisez le modele logique de conception : 
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identifiez les categories de conception a partir des categories d' analyse et 
des frameworks techniques abstraits ; 

isolez les mecanismes communs dans des categories separees afin d' orga- 
niser leur reutilisation ; 

structurez le modele logique suivant les couches logicielles et disposez-y 
les categories identifiees. 

4. Creez les interfaces des categories : 

repartissez les operations d' analyse suivant les couches ; 
identifiez les operations accessibles depuis l'exterieur de la categorie ; 
concevez l'interface des categories conformement aux frameworks tech- 
niques realises. 

5. Mettez au point la presentation des applications : 

elaborez une maquette d'lHM pour les interfaces des applications ; 
reportez la structure des classes d'lHM dans les categories des couches de 
presentation et d' application. 

6. Structurez la configuration logicielle : 

identifiez les sous-systemes a partir des categories de conception ; 
completez la configuration logicielle deja commencee en conception gene- 
rique. 
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Figure 10-27 : Construction de I'etape de conception preliminaire 

Dans le chapitre 11 « Conception detaillee », nous aborderons en detail 
l'elaboration des categories suivantes : 

Presentation: .-Mission, pour illustrer la documentation d'un IHM avec UML ; 

Application: .-Mission, pour montrer comment 1'IHM se couple avec les 

concepts de 1' application ; 

Metier: .-Mission, pour etudier un modele de distribution avec UML ; 
StockageDonnees: .-Mission, pour examiner un modele de persistance rela- 
tionnel a partir d'un schema objet. 



Chapitre Conception detaillee 

li 



Objectifs du chapitre 

Nous arrivons maintenant a la phase ultime de modelisation avec UML. Apres 
la modelisation des besoins puis l'organisation de la structure de la solution, la 
conception detaillee consiste a construire et a documenter precisement les 
classes, les interfaces, les tables et les methodes qui constituent le codage de 
la solution. II s'agit de : 

comprendre le role d'UML pour la conception detaillee ; 

savoir appliquer le micro-processus utilise pour batir une conception objet 

avec UML ; 

apprendre a construire une solution pour : la couche de presentation, la 
couche d' application et la couche metier distribute dont FEAI ; 
savoir transformer un modele objet en modele relationnel. 



Quand intervient la 
conception detaillee ? 

La conception detaillee est une activite qui s'inscrit dans l'organisation 
definie par la conception preliminaire. Le modele logique y est particuliere- 
ment important dans la mesure oil c'est en conception detaillee que Ton 
genere le plus gros volume d'informations. II est ainsi possible de confier les 
categories a des personnes differentes, qui pourront travailler independam- 
ment les unes des autres. La conception detaillee s'appuie done sur les catego- 
ries de conception organisees a la fois suivant les frameworks techniques et les 
regroupements propres au metier. Les concepteurs construisent alors les 
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classes, les vues d'lHM, les interfaces, les tables et les methodes qui vont 
donner une image « prete a coder » de la solution. 

En dernier lieu, il convient de preciser le contenu des sous-systemes de 
maniere a completer la configuration logicielle. Le niveau d' abstraction vise 
par l'etape de conception detaillee est la conception des composants. II s'agit 
d' avoir une idee la plus precise possible pour la fabrication et 1' assemblage 
des sous-systemes de configuration logicielle. 

La conception detaillee precede la phase de codage. A ce niveau, toutes les 
questions relatives a l'agencement et aux details de la solution doivent etre 
modelisees. Ainsi, les interrogations restantes concernent exclusivement la 
bonne utilisation des langages et des outils de developpement. 



Branche 
fonctionnelle 




Conception 
preliminaire 



Branche 
technique 




C onception des composants 



Figure 11-1 : Situation de la conception detaillee dans 2TUP 



Elements mis en jeu 

Micro-processus de conception logique, modele logique, 

proprietes de conception d'une classe, d'un attribut, d'une association et 

d'une operation, 

design patterns : Etat, Iterateur, Curseur, Strategie, Observateur, Refe- 
rence futee, 

couches de presentation, de F application, de metier distribue et de stoc- 
kage des donnees, 
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IHM, distribution RMI, passage d'un modele objet a un modele relation- 
nel, 

modele d' exploitation consolide et modele de configuration logicielle 



Le micro-processus de conception logique concerne la definition des classes a 
implemented C'est done une activite centree sur le modele logique, qui 
combine les diagrammes UML suivants : 

principalement les diagrammes de classes pour preciser la structure des 
classes de developpement, 

mais aussi les diagrammes d' interactions pour preciser les communica- 
tions entre objets, 

et les diagrammes d' activite pour exprimer les algorithmes des methodes. 

Enfin, il est possible de recourir a du pseudo-code pour les algorithmes les 
plus complexes. II s'agit en fait d'esquisser le code des methodes a deve- 
lopper. En 1' occurrence, nous utilisons une formulation proche de Java. 

Le micro-processus consiste en une iteration des cinq activites representees a 
la figure 11-2. 



detaillee. 



Le micro-processus de conception logique 




Classes 
detaillees 



Figure 11-2: Micro-processus de conception detaillee 
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Concevoir les classes consiste a transformer des concepts provenant de 
1' analyse, tels que les metaclasses ou les classes a etats paralleles, en tech- 
niques disponibles avec les langages et les outils de developpement. 
Concevoir les associations definit la facon d'exploiter chaque association 
et les techniques qui seront employees dans le codage. 
Concevoir les attributs necessite essentiellement d' identifier les structures 
de donnees, les iterations et d'autres types complexes permettant de repre- 
senter les attributs d' analyse avec le langage utilise. 

Concevoir les operations permet de determiner le contenu des methodes 
complexes et d' identifier en cascade de nouvelles classes et operations 
dans la categoric 

Valider le modele constitue la phase de decision du cycle iteratif. Sortir de 
ce cycle signifie que le modele donne 1' image prete a coder de ses compo- 
sants de configuration logicielle. 

Nous allons etudier tour a tour ces activites, puis voir leur application sur les 
differentes couches du systeme SIVEx. 

Concevoir les classes 

Les classes qui proviennent de l'analyse ne sont pas toujours conformes aux 
possibilites du langage d' implementation. Dans certains cas, une analyse 
orientee objet est realisee dans un langage non objet. La transformation des 
classes en codage est alors particulierement importante pour conserver la trace 
du passage de l'analyse au code. Java offre bien entendu une transformation 
beaucoup plus directe. Certaines formes telles que les metaclasses, les etats ou 
les heritages multiples sont cependant tolerees par les analystes mais incon- 
nues de Java. Concevoir les classes consiste tout d'abord a expliciter comment 
ces concepts devront etre traduits dans le code. 

Concevoir les classes, c'est aussi en introduire de nouvelles soit pour prendre 
en charge des responsabilites purement techniques, soit pour decharger une 
classe d' analyse de certains de ces aspects techniques. Les liens qui rattachent 
ces classes entre elles doivent le plus souvent correspondre a des design 
patterns. On trouvera a terme des classes comme des « fabriques », des 
« archiveurs », des « traceurs », des « verificateurs de coherence », etc. 

Concevoir les classes, c'est enfin redistribuer les messages et les evenements 
du modele dynamique sur les differentes couches de conception - nous 
verrons notamment comment realiser la conception orientee objet des 
messages identifies dans les interfaces EAI. II est probable en effet que ces 
concepts vus de maniere abstraite par l'analyste ne correspondent plus aux 
principes de conception. Pour les systemes 3-tiers, nous pensons plus 
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particulierement a la redistribution des echanges entre les couches metier et 
application. Ces echanges s'appuyant sur les capacites d'un reseau physique 
doivent faire l'objet d' optimisations. Dans cette optique, il convient que les 
diagrammes d'etats soient retravailles au niveau de la conception. 

LE DESIGN PATTERN ETAT 

Le design pattern Etat [Gamma 95] est une facon de concevoir le diagramme 
d'etats d'une classe d'analyse. La gestion des etats est deleguee de sorte qu'a 
chaque etat corresponde une classe du patron. Une classe gere ainsi les acti- 
vites et les transitions attachees a l'etat qu'elle represente. 

Le diagramme d'etats du suivi de mission sert a illustrer 1' application de ce 
design pattern. Chaque etat de la classe correspond a une specialisation de la 
classe SuiviMissionEtat. Les evenements du diagramme d'etats deviennent 
des operations polymorphes pour les classes Etats. L interpretation du 
diagramme d'etats de la figure 11-3 donne ainsi une conception de la classe 
SuiviMission, accompagnee d'un environnement de gestion de ses etats (voir 
figure 11-4). 



depart 



r 



en route 



incident / creerlncidentTransport( type) 



depart etape / recalculerTemps 



arrivee etape / recalculerEtapes 



retour 




en etape 



incident / creerlncidentEtape 



Figure 11-3 : Diagramme d'etats de la classe SuiviMission 
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SuiviMission 



/ heureDepart 
/ heureArrivee 



departO 
retourO 

arriveeEtapeQ 
departEtape() 
incidentQ 



delegue " eta ' 


SuiviMissionEtat 


1 


arriveeEtapeO {ignore} 
departEtapeO {ignore} 
incidentO {abstract} 
retourQ {ignore} 







SuiviMissionEnRoute 




SuiviMissionEnEtape 


arriveeEtapeO 
departEtapeO 
incidentO 
retourO 




arriveeEtapeO 
departEtapeO 
incidentO 
retourQ 



Figure 11-4 : Environnement resultant des etats de la classe SuiviMission 



La classe SuiviMission delegue la gestion de ses etats a la classe SuiviMission 
Etcit ; en d'autres termes, elle transmet systematiquement les evenements 
qu'elle recoit. Les etats de la classe sont ensuite charges de declencher les 
operations et d' assurer les transitions. Le diagramme de communication ci- 
apres vous montre comment un tel mecanisme peut etre documente. 



> 



1 . arriveeEtape 



: SuiviMission 
[etat = enRoute] 



Objet representant un 
client appelant les 
operations de la classe. 



1.1.1.1 «become» 



: SuiviMission 
[etat = enEtape] 



1.1 arriveeEtape 



1.1.1 etat= enEtape 

1.1.2 recalculerEtapes 



enRoute : SuiviMissionEnRoute 



enEtape : SuiviMissionEnEtape 



Figure 11-5: Dynamique d'un changement d'etat sur une arrivee d'etape 

Le design pattern Etat reduit la complexite des methodes par extraction des 
instructions d'aiguillage necessaires a la gestion des transitions. De ce fait, il 
facilite l'ajout de nouveaux etats. La prise en compte d'un super-etat se resout 
tout aussi facilement par l'introduction d'une super-classe etat (voir 1' etude de 
cas ci-apres). 
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Lorsque les classes representant les etats ne possedent aucun attribut, il est 
souvent possible d'en faire des singletons. L'instruction associee a une transi- 
tion d'etat prendra alors la forme suivante : etat = SuiviMissionEn 
Etape.getlnstance( ). 



ETUDE DE CAS : CONCEPTION DES ETATS DE LA CLASSE MISSION 

La realisation des etats de la classe Mission s'etablit a partir du diagramme d'etats de la classe 
d'analyse (voir chapitre 8). Le diagramme d'etats elabore par I'analyste regroupe a la fois des 
aspects de niveau application et metier. En effet, les transitions et les activites qui concernent 
I'affectation des valeurs sont d'ordre applicatif, tandis que les etats de creation, validation, annu- 
lation et realisation concernent la couche metier. Le concepteur s'appuie done sur de nouveaux 
diagrammes d'etats de conception pour les classes Metier::Mission::Mission et Application: :Mis- 
sion::DocMission. A cet egard, reportez-vous respectivement aux figures 1 1-6 et 11-8. 

Au niveau de la couche metier, les evenements d'affectation et de modification sont simplifies de 
maniere a alleger les echanges RMI lors de la creation d'une nouvelle mission. II n'en resulte 
done que deux sous-etats, suivant I'etat correct ou incorrect determine par une operation de veri- 
fication. 



creer( type, nom. destination, hDepart ) 





en creation 



modification / veriderMission 

when( nbErreur > 0 OR status = incomplet ) 



correcte 



jf when( nbErreur = 0 AND status = complet ) 



incorrecte 



valider 
JL — 



modifier! < 1h avant depart ] 



depart / creerSuivi 



vahdee 



annuler / libererRessources 



en realisation 



retour / archiver 



Figure 11-6: Diagramme d'etats simplifie de la classe Mission au niveau de la couche Metier 

L'environnement de la classe Mission apres I'application du design pattern Etat est done illustre a 
la figure 11-7. Vous remarquerez le devenir des sous-etats en tant que sous-classes dans la hie- 
rarchie des classes d'etat. Toutes les sous-classes finales dans la hierarchie des etats implemen- 
tent le design pattern singleton. 
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Mission 



-etat 




MissianEtat 


> 

1 





3 



MissionEtatEnRealisation 
{singleton} 



MissionEtatValidee 

{singleton] 



MissionEtatEnCreation 



MissionEtatCorrect 
{singleton} 



MissionEtatlncorrect 
{singleton} 



Figure 11-7 : Environnement de gestion d'etats de la classe Metier::Mission::Mission 

Pour fixer les idees, voici le code Java correspondant a la structure et la distribution des opera- 
tions sur les classes Bat. En premier lieu la classe Mission delegue a son etat le traitement des 
evenements du diagramme d'etats. 



package 
import 



SIVEx . metier . mission . mission; 

SIVEx .metier .mission .mission . etats; 



public class Mission { 

private MissionEtat _etat; 



// Operation reservee qui permet aux etats de transiter 
public void setEtat ( MissionEtat newEtat) { 
_etat = newEtat; 

} 

// reception des evenements du diagramme d'etats : 
public void modification (this, ...) { 
_etat . onModification (this) ; 

} 

public void erreursOuIncomplete () { 
_etat . onErreurOuIncomplete (this) ; 

} 

public void justeEtComplete () { 
_etat . onJusteEtComplete (this) ; 

} 

public void valider () { 
_etat . onValider (this) ; 

} 

// etc... 
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Par la suite, chaque etat gere les transitions sur la classe Mission. Les classes representant des 
super-etats fournissent des operations factices, qui peuvent declencher un message d'erreur, 
dans la mesure ou un fonctionnement normal ne devrait jamais les utiliser. 



package SIVEx . metier . mission . mission . etats; 

abstract public class MissionEtat { 

public void modification( Mission sujet) { 

FichierTrace . instance (). tracer ( «ERREUR : etats mission : ...»); 

// etc... 

2 

package SIVEx .metier .mission .mission . etats; 

public class MissionEtatEnCreation extends MissionEtat { 
public void onModification( Mission sujet, ...) { 

// traitement de l'evenement au niveau du super-etat . 
sujet .modifier ( ...) ; 

sujet .verifier () ; // declenche de nouveaux evenements. 

}; 

2 

package SIVEx .metier .mission .mission . etats; 

public class MissionEtatEnCreationCorrecte extends MissionEtatEnCeation { 
// realisation du singleton : 
private static MissionEtat _instance; 
public static MissionEtat instance () {...} 

// realisation des evenements qui concernent le sous-etat : 
public void onValider (Mission sujet) { 
// transition : 

sujet . setEtat ( MissionEtatValidee . getlnstance () ) ; 

} 

2 

En ce qui concerne la couche application, le nouveau diagramme d'etats montre la prise en 
compte des controles au niveau du poste client, a charge pour la classe Mission de fournir une 
seule operation de verification lors de la creation ou de la modification d'une mission dans la 
couche metier. Le design pattern Etat est egalement applicable au niveau de la classe DocMission. 
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en modification 



affecterCmd( cmd ) / verifierTonnage 

affecterVehicule( v ) / verifierTonnage, verifierQualification 

affecterChauffeur( ch ) / verifierQualification 



creer( type, nom, destination, hDepart ) 



modifier! * 1 h avant depart ] 
valider / mission. sauvegarder 



ouvrir( nom ) / charger 




Figure 11-8 : Diagramme d'etats de la classe DocMission au niveau de la couche application 



L' identification des classes a partir des interfaces EAI illustre egalement 
comment les elements du modele dynamique, cette fois-ci les messages, 
alimentent de nouvelles classes. En effet, pour des raisons de maintenance des 
modeles d'echanges, il est important de donner une tournure orientee objet a 
l'EAI, meme si les outils qui l'implementent proposent par defaut une separa- 
tion forte des donnees et des fonctions. 

Le travail realise en conception preliminaire donne deja une premiere orienta- 
tion objet au travers de la matrice qui a servi a identifier les interfaces EAI et 
par la semantique « objet.verbe » des messages utilises dans les diagrammes 
de sequence. 



ETUDE DE CAS : CONCEPTION DES MESSAGES EAI « CLIENT » 

A partir de I'identification de I'objet client, present sur plusieurs interfaces d'echanges EAI, le tra- 
vail consiste a etablir la structure d'un client au vu des differentes interfaces auxquelles il parti- 
cipe. 

Typiquement, un message EAI est compose d'un en-tete contenant les informations d'identifica- 
tion de I'objet, et ce afin de minimiser le volume d'informations a envoyer lorsqu'une simple refe- 
rence a I'objet concerne par le message suffit. Par ailleurs, et suivant les differentes interfaces, 
I'echange d'un objet client est assorti d'adresses, d'informations comptables ou de contacts. En 
consequence, I'utilisation d'un diagramme de classes supporte la conception orientee objet des 
messages EAI en mettant en valeur les agregations, voire les heritages, necessaires a la structu- 
ration des donnees echangees. 
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<<evenl» 
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< 
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Figure 11-9 : Conception orientee objet des messages identifies dans les interfaces EAI 

Le diagramme ci-dessus montre la conception des messages EAI, remarquez la reutilisation du 
stereotype « event » pour differencier les classes qui sont echangees des blocs d'attributs qui 
les accompagnent. Par ailleurs, la transformation des verbes, provenant des messages identifies 
en conception preliminaire, en operations permet d'identifier rapidement quelle structure de don- 
nees accompagne le message. Ainsi le message « client.supprimer » transports la structure de 
donnees decrite par la classe EnteteClient, tandis que le message « client. mettreAjour » trans- 
ports celle qui correspond a la classe Client. 



Concevoir les associations 



L' association est un concept inconnu de la plupart des langages orientes objet. 
Elle se transforme en attribut ou en tableau d'attributs suivant sa multiplicite. 
La figure 11-10 montre 1' application de ce principe a deux associations de la 
classe Metier: :MissionTmction. 



MissionTraction 



destination 



Agence 



transporte 



MissionTraction 



destination : Agence 

IstCommande : Vector<Commande> 



Commande 



Figure 11-10 : Exemple d'une conception d'associations par des attributs 
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La figure ci-dessus montre qu'une agregation, outre la precision semantique 
qu'elle apporte en analyse, n'est pratiquement jamais prise en compte en 
conception. Remarquons egalement que 1' utilisation du tableau generique 
Vector ou ArrayList de Java ne permet pas d'exprimer le type d'elements 
stockes (nous donnons par la suite indifferemment des exemples avec Vector 
ou ArrayList, le principe est le meme). L'usage d'une notation empruntee au 
template de C++ permet de conserver cette information sur le diagramme. 
Remarquons enfin que la conception des associations est facilitee par 
l'expression de leur navigabilite. 

II serait cependant fastidieux de transformer tous les diagrammes de concep- 
tion, d'autant que la conception d'une association s'accompagne d'un 
ensemble d'operations necessaires a sa gestion. On utilise done une valeur 
etiquetee, design tip, pour designer les mecanismes d' association accompa- 
gnes de leurs operations de gestion. Souvenez-vous, nous avons deja utilise la 
meme technique en conception generique. Ce mecanisme doit done etre docu- 
ments dans le modele, comme l'illustre la figure ci-dessous. 



MissionTraction 



(design tip = default} 

destination L 1 



transporte 



Agence 



(design tip = default} 



Comma nde 



Detail des attributs et des operations mis 
en ceuvre par defaut : 



MissionTraction 



destination : Agence 

IstCommande : ArrayList<Commande> 



ajouterDestination(a : Agence) : boolean 
destination() : Agence 

ajouterCommande(c : Commande) : boolean 
retirerCommande(c ; Commande) : boolean 
listerCommandeO : ArrayList <Commande> 



Figure 11-11 : Documentation du mecanisme {design tip = default} 

La visibilite des operations de gestion de F association etant identique a la 
visibilite du role, il est important d'introduire cette information en conception 
detaillee. 

La conception d'une association se complique lorsqu'elle comporte des 
contraintes a respecter. On peut considerer deux types de contraintes diffe- 
rentes et adapter le style de conception en consequence. 

Les contraintes de gestion sont exprimees par une multiplicite minimale 
superieure a 0 (obligatoire), une composition, un qualifieur ou les proprie- 
tes d'UML {ordered}, {addOnly} et {frozen}. Ces contraintes ont des 
repercussions sur F interface et les methodes de gestion d'une seule asso- 
ciation. Par exemple : Foperation de retrait peut disparaitre du fait d'un 
addOnly ou d'un frozen ; le constructeur doit comporter des parametres 
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supplementaires pour initialiser les liens obligatoires. Une composition se 
traduit par une regie de structure : la destruction du composite implique 
celle de ses sous-parties ; cette contrainte a toutefois peu d'influence 
appliquee a Java du fait de son ramasse-miettes. Enfin, les qualifieurs 
transforment un Vector en Hashtable et une ArrayList en HashMap dont la 
cle est le qualifieur. 

D'autres contraintes structure lies portent sur plusieurs associations : il 
peut s'agir des contraintes utilisateur, des contraintes predefinies {XOR}, 
{subset} et {AND}, des associations bidirectionnelles ou d'une classe 
d' association. Ces contraintes induisent des postconditions aux operations 
de gestion de 1' association. Les associations bidirectionnelles sont concues 
exactement comme deux associations reciproques, dont les attributs de 
part et d' autre sont synchronises par des regies de gestion. Une classe 
d' association devient un point central qui gere la relation avec les deux 
autres classes. 

Concevoir les associations consiste enfin a transformer les relations n-aires, 
tolerees par les analystes, en relations binaires alors plus faciles a concevoir, 
ou bien a ajouter une nouvelle classe qui pilote la relation complexe. 

Dans un second temps, il est possible d'optimiser les methodes de gestion. Le 
cas le plus frequent concerne la consultation d'une liste d'objets en mode 
client/serveur. D'une part, le transfert d'un groupe d'objets est couteux pour le 
reseau, alors qu'il suffit d'afficher un seul libelle caracteristique pour chaque 
objet. D' autre part, au-dela de 10 a 20 references, un utilisateur reformule la 
plupart du temps son critere de selection. Pour eviter des temps d'attente, il est 
souvent utile de proceder a la gestion d'une liste de libelles caracteristiques, 
par un curseur ramenant 10 a 20 references a la fois. 



ETUDE DE CAS : CONCEPTION DES ASSOCIATIONS DANS 
METIER: .MISSION 

La conception des associations consiste ici a completer le nom des roles et la navigabilite des 
associations. Pour la plupart, une application du mecanisme par defaut suffit a decrire les attri- 
buts et les operations d'implementation. 

Seule la classe d'association liant une mission de tournee a ses etapes doit etre explicitee. Dans 
ce cas, le [design tip = ignore) signifie que I'association reste sur le diagramme aux seules fins 
d'une meilleure lisibilite, mais qu'elle est explicitement congue par les attributs et les operations 
disponibles sur la classe MissionTournee. 

La figure ci-dessous montre la structure resultant des classes de la categorie. 
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MissionTraclion o 



{design lip = default} 
transpone 



{design tip = default} 



Chauffeur 



1 
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destination 
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chauffeur t 0..1 {frozen} ^depart 



comma nde 



IncidentEtape 



Commande 
1 A 



{frozen} 



commande 
{design tip = default} 



incident 



concerne 

{design tip = default} 
1 



{design tip = default} 

esf affects tut 



, {design tip = default} 



Vehicule 



0.1 vehicule 
{design tip = default} 
est altecte sur 

l 



-O 



Mission 



{design tip = ignore} 




mission I 1 
{frozen} 

surveille 
{design tip = default} 

0.1 



SuiviMission 



noEtape 



MissionDeTournee 



lypeDeToumee 

IstEtapes : HashMap<int,Etape> 



ajouterEtapefcmd : Commande) : boolean 
retirerEtape(noEtape : int) : boolean 
ordonnerEtapes() : boolean 

permuterEtapes(noEtape1 : int. noEtape2 : int) : boolean 
listerEtapes(s : Site, c : Commande) : ArrayList<Etape> 



{design tip = default} 






{ordered} * , 


evenement 

I 




EvenementMission 













a lieu en 



Site 

lieu 
0..1 



{design tip = default} 

Figure 11-12 : Associations de la categorie Mission, documentees 
pour la conception detaillee 

Le code Java ci-dessous montre la realisation par defaut de I'association entre la classe Etape et 
IncidentEtape. L'aspect systematique de ce code souligne I'avantage d'utiliser un generateur de 
code, conformement aux preconisations « Model Driven » de I'OMG 



package SIVEx. metier .mission; 

public class Etape { 

// realisation de I'association avec les incidents d' etape 
private Vector_incident ; 



// operations de gestion : 

public Boolean ajouterlncident ( IncidentEtape inc) { 
_incident . addElement ( inc) ; 
return true; 
} 

public Boolean retirerlncident ( IncidentEtape inc) { 
int _incident . removeElement ( inc) ; 
return true; 
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LE DESIGN PATTERN ITERATEUR 

Le design pattern Iterateur [Gamma 95] est une facon de concevoir Faeces 
sequentiel a un ensemble d'objets, sans avoir a exposer la structure interne 
de l'ensemble. Par ailleurs, l'iterateur offre une interface de parcours stan- 
dard qui uniformise et facilite la manipulation des differents types de liste 
d'un meme projet. II offre enfin la possibility de parcourir simultanement et 
independamment le meme ensemble d'objets par des taches paralleles. 



L'objectif de l'iterateur est de deleguer les operations de parcours d'une associa- 
tion. Par ailleurs, il a pour role de gerer l'etat d'un element courant, auquel on peut 
acceder sequentiellement au precedent ou au suivant. L'iterateur est done particu- 
lierement approprie aux associations ordonnees (propriete {ordered}). 

La structure d'un iterateur repond au diagramme de la figure 1 1-13 ; la classe 
responsable de gerer l'association sert naturellement de fabrique d'iterateur. 



MissionTraction 



transpose 



{design tip = iterateur} 
comman de ^ . 



Commande 



«lnterface» 
Iterateur 



premierO I Objet 
suivant() : Objet 
precedent)) : Objet 
eltCourantQ : Objet 



<J--- 



Detail des attibuts et des operations mis 
en oeuvre avec iterateur : 



MissionTraction 



destination : Agence 

IstCommande : Vector<Commande> 



ajouterDestination(a : Agence) : boolean 
destination() : Agence 

ajouterCommande(c : Commande) : boolean 
retirerCommande(c : Commande) : boolean 
IterateurCommandeO : IterateurCommande 



accede a IstCommande 



IterateurCommande 



indexCommande : int 



premierO 
eltCourantO 
suivantO 
precedentQ 



Figure 11-13 : Documentation du mecanisme {designTip=iterateur} 
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Un curseur est un derive d'iterateur qui renvoie a chaque requete un nombre 
determine d'elements. Nous allons maintenant le mettre en ceuvre dans le 
cadre de 1' etude de cas. 



ETUDE DE CAS : CONCEPTION D'UN CURSEUR ENTRE AfiENCE 
ET MISSION 

Nous allons maintenant passer a la phase d'optimisation des associations. L'acces aux missions d'une 
agence pour une plage de dates donnee est une operation frequente du repartiteur, des operateurs 
de quai et des receptionnistes. Par ailleurs, cette operation est parallele, car elle s'appuie sur le reseau 
et requiert par consequent plus d'attention en matiere de volume et de temps d'acces. 



CursMissionAgence 

agence 
daleDepartl 
dateOepar12 
site = null 
typeMission = null 
nbEltParPaquet = 10 



reinilialiser(date1 : Date, date2 : Date, site : Site = null, typeMission : int = null) : boolean 
premierO : Vector<String> 
suivantO : Vector<String> 
precedentQ ; Vector<String> 



Mission 

nomldentification : String {frozen} 
commentaire : String {changeable} 
dateDepart : Date {changeable} 
/ libCaracteristique : String {readonly} 



verifierQualification(err : String) : boolean 
verifier Tonnage(err : String) : boolean 
calculerTrajetO 

affecterCommandefcmde : RrEntCommande) : boolean 
affecterChauffeur(ch : RrEntChauffeur) : boolean 
affecterVehicule(veh : PtrEntVehicule) : boolean 
validerO : boolean 
invalided : boolean 

signalerDepart(hDepart : Date) : boolean 
completerTrajet(EntlnfoTrajet) : boolean 
desaffecterRessourcesO : boolean 
desaffecterCommande(noOrdreCmde : int) : boolean 
creerCursMissionAgence(ag : Agence) : CursMissionAgence 



{ libCaracteristique = nomldentificatbn(32) 
+ " ■+dateDepart.heureMinutes } 

Figure 11-14 : Structure d'un curseur parcourant les missions concernees par une agence 

Le developpement d'une classe curseur parcourant les libelles caracteristiques des missions se 
justifie done en prevision de la distribution aux applications clientes de I'information. En effet, des 



depart 
{design tip 



Agence 

"7rV 



1 

{frozen} 
default} 
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listes de selection de missions sont notamment gerees par les applications ConVEx deployees 
sur le poste de travail du receptionniste. 

La fabrication d'un curseur est une operation de classe ; elle correspond a une responsabilite sur 
la classe Mission. La construction d'un curseur specifie une agence, car il s'agit de recenser les 
missions d'une agence. Cette technique permet de respecter le sens de la dependance entre la 
categorie Ressource a laquelle appartient le concept d'agence et la categorie Mission. 

Le curseur distribue des tableaux de libelles caracteristiques au travers des operations premierf), 
suivantQ et precedents L'attribut nbEltParPaquet permet de redimensionner la taille des tableaux. 



Concevoir les attributs 

La conception des attributs consiste principalement a definir le type des attri- 
buts identifies en analyse. Bien que la plupart des attributs se satisfassent des 
types de base de Java, certains attributs d' analyse correspondent a une struc- 
ture de donnees qu'il est necessaire de specifier. Dans ce cas, nous introdui- 
sons le stereotype struct pour distinguer une simple structure de donnees 
d'une classe. Cette derniere s'apparente a un type de base du langage ; tous 
ses attributs sont publics, de sorte qu'elle necessite rarement d'operations 
associees. D'autres attributs induisent des enumerations pour lesquelles nous 
introduisons egalement le stereotype enum. En Java, une enumeration corres- 
pond a une classe composee d' attributs public static final. 

Concevoir les attributs, c'est egalement specifier leur visibilite et leur mode 
d'acces. Par defaut, un attribut est prive et ce principe reste invariable dans 
notre conception. La prise en compte des proprietes UML {changeable}, 
{readonly} ou {frozen} est done implicitement geree par des operations 
d'acces. 

Pour assurer respectivement la modification et la lecture de la valeur de 
l'attribut, les attributs {changeable} requierent deux operations seKnom 
attribut> et get<nom attribut>. La propriete {frozen} implique F initialisation 
de l'attribut dans le constructeur de la classe. Cela se traduit le plus souvent 
par un parametre d' initialisation supple me ntaire. Nous avons ajoute la 
propriete {readOnlyj pour indiquer que l'attribut n'est disponible qu'en 
lecture grace a 1' operation get. 

Enfin, concevoir les attributs, c'est specifier les methodes qui servent a la mise 
a jour des attributs derives. II existe a cet effet plusieurs techniques, la plus 
simple consistant a invoquer une operation de mise a jour lors de Faeces a 
l'attribut. Certaines methodes de calcul peuvent cependant etre couteuses ou 
frequentes, aussi faut-il gerer un attribut d'etat pour recalculer l'attribut derive 
uniquement si Foperation se justifie. La gestion des attributs derives dans une 
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application multitache necessite parfois la conception de synchronisations 
complexes. 



identification String {frozen} 
nomUsuel String {changeable} 
/CARealise HashMap<int,Devise> {readonly} 
typeClient TypeClient {frozen} 
{changeable} 



Client(identrfication String, type TypeClient) 
getldentificationO String 
getNomUsuel{) String 
setNomUsuel{nom String) 
recalculerCAReahse() 
getCARealiseO HashMap<int.Devise> 
getTypeClient() String 
getAdressef) Adresse 
setAdresse(adr Adresse) 



Structure et enumeration induites 




Operations induites 



«enum>> 
TypeClient 



particular int = 0 
pmelnf50p mt = 1 
pmeSup50p int = 2 



ise mt = 3 
filhaleGroupe mt = 4 
qroupe mt = 5 



«struct>> 
Adresse 



noRue String 
nomRue String 
complement String 
codePostal : String 
nomVille String 
Pays : String 



Figure 11-15: Mecanismes induits par la definition des attributs 



La conception des attributs des classes de la categorie Mission ne pose guere de problemes, les 
methodes de calcul des attributs derives correspondront a la transcription en langage Java des 
contraintes specifies par I'analyste. 



Mission 



nomldentification String {frozen} 
commentaire : String {changeable} 
dateDepart Date {changeable} 
/ libCaracteristique : String {readonly} 



Etape 



nbColisEffectif : int {changeable} 
montantPaiement int {changeable} 
/ modePaiement ModePaiement {changeable} 
/ adresse Adresse {readonly} 
/contactMission : Contact {readonly} 



IncidentMission 



typelncident : Typelncident {frozen} 
raison : String {frozen} 



EvenementMission 



typeEvenement TypeEvenement {frozen} 
heureEvenement Date {frozen} 
messageChauffeur String {changeable} 



DescriptionTrajet 



dureeEstimee Duree {changeable} 

/peage : Devise {readonly} 

/ limitations : ArrayList<String> {readonly} 

/ preconisation : Stnng {readonly) 

/ traitements ArrayList<String> {readonly} 



SuiviMission 



/ heureDepart Date {readonly} 
/ heureArnvee : Date {readonly} 



IncidentEtape 



reponseRepartiteur String {changeable} 



IncidentTrajet 



etardEstime : Duree {changeable} 



Figure 11-16: Definition des attributs surles classes de la categorie Metier::Mission 
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A titre d'exemple, les structures et enumerations induites par la conception des attributs sont 
detaillees a la figure 11-17. 



«struct» 
ModePaiement 



typePaiement : TypePaiement 
typeCarte : Carte 
noReference : String 
banque : String 
majoration : int 



«struct» 
Contact 



nom : String 
service : String 
fonction : String 
noTelephone : String 
noFax : String 
adresseSurSite : String 



«enum» 
TypeEvenement 



«enum» 
Typelncident 



Figure 11-17 : Classes derivees de la conception des attributs 

Les choix de realisation des attributs induisent done la realisation du code suivant. Nous avons 
pris pour exemple la classe Mission qui possede les trois types de proprietes. 



package 



SIVEx. metier .mission; 



public class Mission { 

// realisation des attributs : 
private String _nomIdentification; 
private String _commentaire ; 
private Date _dateDepart; 

// libCaracteristique pas declare car e'est un attribut derive 



// Constructeur avec les attributs frozen : 
public Mission ( String nomldentification) { 
_nomIdentification = nomldentification; 

} 

// Acces en lecture : 

public String getNomldentification () { 
return _nomIdentification; 

} 

public String getCommentaire () {...} 
public Date getDateDepart ( ) {...} 
// Calcul des attributs derives : 
public String getLibCaracteristique () {...} 
// Acces en ecriture 

public void setCommentaire ( String commentaire) { 
_commentaire = commentaire; 

} 

public void setDateDepart ( Date dateDepart) { ...} 
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Concevoir les operations 

La conception des operations constitue la derniere etape du micro-processus 
de conception. Le plus gros du travail est certainement fourni lors de cette 
etape. II s'agit en effet de donner une image assez precise du contenu des 
methodes du projet. 

Pour concevoir ou documenter une methode, UML met a notre disposition 

toute la palette des diagrammes du modele dynamique. 

Un diagramme d'activite permet de decrire une methode pour laquelle peu 
de classes differentes interviennent. Ce diagramme se revele efficace lors- 
que la methode met en jeu un algorithme avec des etapes et de nombreuses 
alternatives. 

Un diagramme d' interactions expose au contraire une methode faisant 
intervenir plusieurs classes, mais avec peu d' alternatives. 

Certaines methodes sont concues avec des etats stables de calcul intermediate 
et necessitent un contexte de variables pour memoriser leur avancement. Ces 
methodes peuvent correspondre a une classe de conception avec des etats/ 
transitions. Cette technique de transformation d'une methode d' analyse en 
classe est depuis longtemps connue des concepteurs objet ; cela s'appelle la 
reification. 

REIFICATION 

Reifier consiste a traiter en objet ce qui n'est pas usuellement considere 
comme un objet [UML-RM 04] et [Rumbaugh 91]. 

Cette technique est particulierement utile pour transformer des comporte- 
ments dynamiques, tels que processus, taches, activites, en classes que Ton 
peut stocker et associer avec d'autres elements du modele. La reification de 
methodes permet de realiser des delegations lorsqu'une classe concentre trop 
de roles (syndrome de la classe obese) ; c'est un principe de conception cou- 
ramment employe pour apporter plus de souplesse et devolution a la solu- 
tion mise en ceuvre. 

Dans la mesure ou la classe issue d'une reification de methode decrit un 
processus, un diagramme d'etats peut etre utilise pour decrire les etats qu'elle 
realise. Ce diagramme montrant des successions d' actions et d' activites 
s'apparente a un diagramme d'activite. 

En pratique, la description des methodes permet d' identifier de nouvelles 
responsabilites techniques a assigner aux differentes classes du systeme. C'est 
ainsi qu'apparaissent tantot de nouvelles operations sur les classes existantes, 
tantot de nouvelles classes techniques provenant de 1' application de design 
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patterns. Les nouveaux elements de modelisation alimentent alors une 
nouvelle iteration sur le micro-processus de construction jusqu' a Fobtention 
d'un modele facile a coder. Ce processus suit le principe d'une approche 
top-down (du plus abstrait vers le plus detaille), mise en place a l'aide des 
techniques traditionnelles de decomposition fonctionnelle. 

LE DESIGN PATTERN STRATESIE 

Le design patten Strategie [Gamma 95] consiste a encapsuler une famille 
d'algorithmes qui s'executent dans un contexte identique. La strategie utilise 
la reification pour transformer les algorithmes en classes, puis l'heritage 
d' interface pour organiser ces classes en arbre de specialisation. 



Le diagramme de la figure 11-18 indique le schema nominal d'une strategie 



Contexte 




«lnterface» 
Strategie 


pa ram 


Contexte(s : Strategie) 
excuterStrategieQ 


© 

1 


executer(contexte : Contexte) 






/ 



StrategieConcreteA 



Strateg ieConcrete B 



StrategieConcreteC 



Figure 11-18 : Structure du design pattern Strategie. 

Le contexte d'une strategie sert a la fois de receptacle a ses parametres 
d' entree/sortie, et de declencheur de son comportement. Le mode d' utilisation 
d'une strategie est illustre par le diagramme de sequence de la figure 11-19. 
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Figure 11-19 : Dynamique de fonctionnement du design pattern Strategie 

On recourt a une strategie lorsqu'on a besoin de differentes variantes de com- 
portements s'executant en fonction de conditions exterieures a une classe. On 
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utilisera generalement une strategic pour developper des variantes depen- 
dantes d'un parametrage ou d'un choix utilisateur. Une strategic sert egale- 
ment a organiser les differents comportements d'une hierarchie de classes 
dotees de la meme operation. 

ETUDE DE CAS : CONCEPTION D'OPERATIONS 
DANS METIER: .MISSION 

Operation Mission ::signalerDepart : 

Le signal de depart d'une mission entraine une chaine de messages dans le systeme qui permet 
la mise a jour des informations d'encours de commande. Un diagramme de sequence est le plus 
approprie pour documenter ce type de methode mettant en jeu plusieurs classes differentes. 



: SuiviMission 



signalerDepart(Date) 




lesCommandes = IstCommandesQ 

i< 



plepartAgencef Date) 



commande. enCours : En 
CoursDeCmd 



: PassageDe 
Crnd 



loop i=1 .nbCommande ) I 



setDepartAgence(Date) 



I recalculerDatesPassage 



recalculerDateLivraison 



Figure 11-20 : Conception de Mission::signalerDepart 
au travers d'un diagramme de sequence 

Cette sequence de messages correspond aux methodes decrites ci-apres pour la classe Suivi- 
Mission et I'operation EnCoursDeCmd ::DepartAgence. 



package SIVEx. metier .mission; 
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Vector lesCmd = _mission . IstCommandes () ; 

Commands cmd; 
EnCoursCommande ecmd; 
for( i = 0; i < lesCmd. size () ; i++ ) { 

cmd = (Commande) lesCmd. element At ( i) ; 

ecmd = cmd. encours () ; 

ecmd. setDepartAgence ( _mission . getDateDepart () ) ; 

} 




} 



package SIVEx. metier . commander- 
public class EnCoursCommande { 

public void setDepartAgence (Date date) { 
_departAgence = date; 
recalculerDatesPassages () ; 
recalculerDatesLivraison () ; 

} 

} 



Operation MissionDeTournee::ordonnerEtapes : 



La fonction Ordonner les etapes offre au repartiteur un calcul d'agencement des etapes sur un 
parcours en fonction de criteres de rapidite d'execution, de distance minimale ou d'urgences a 
traiter. C'est une methode construite sur un algorithme de recherche ; elle comporte des etapes 
d'avancement et des alternatives de calcul dependant d'urgences a positionner sur le parcours. 
Cette methode ne fait appel a aucune autre operation d'autres classes et sa description fait 
apparattre de nouvelles operations privees de gestion interne. Un diagramme d'activite est dans 
ce cas le plus approprie pour representer cette methode. 

Par ailleurs, le calcul d'ordonnancement reclame un environnement compose de differents 
tableaux de classement et de diverses operations specifigues. C'est pourquoi nous avons choisi 
de reifier I'operation en une classe OrdonnateurDEtapes qui a pour attributs les variables du 
contexte de calcul et pour operations les activites de I'algorithme. Les diagrammes ci-apres 
documentent la structure statique et fonctionnelle de cette classe. 
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MissionDeTournee 



noEtape 



-tram 



exeiute 



V 



0..1 

laMission 
{frozen} 

{design tip = default} 



OrdonnateurDEtapes 



tabResultat : ArrayList<Etape> 
tablnitial : ArrayList<Etape> 
tabUrgence : ArrayList<boolean> 



executer(laMission : MissionDeTournee) 
initialiserO 

positionnerDepartRechercheO 
rechercherEtapeSuivanteO : int 
rechercherEtapeSuivanteOptimaleO I int 
ordonnerResultatO 
ordonnerMissionQ 



Etape 
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3» 

0.1 



{frozen} 
commande 

1 1 



Commande 



Figure 11-21 : Structure de 1' operation reifiee OrdonnateurDEtapes 
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initialiser 



PositionnerDepartRecnercne 
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OrdonnerResultat 






< 



else 



Figure 11-22 :Activites de /'operation OrdonnateurDEtapes::executer() 
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Le diagramme d'activite correspond au code Java suivant pour la classe OrdonnateurDEtapes 

package SIVEx .metier .mission; 

class OrdonnateurDEtapes { 

public OrdonnateurDEtapes ( Mission laMission) { 
int i; 
_laMission = laMission; 
_tablnitial = laMission . IstEtapes () ; 
_tabUrgence = new Boolean [_tablnitial . size ()] ; 
for ( i = 0; i < _tablnitial . size () ; i++ ) { 

Etape etape = (Etape) _tablnitial .elementAt (i) ; 
_tabUrgence [i] = etape . commande . estUrgente () ; 

} 

} 

public void executer() { 
int err = 1; 
_initialiser () ; 

// tant qu'il reste des etapes a traiter : 

while ( _tabResultat . size () < _tablnitial . size () && err > 0) { 
_positionnerDepartRecherche () ; 

if ( _tabUrgence . size () > 0 ) // reste des urgences 

err = _rechercherEtapeSuivanteOptimale () ; 
else 

err = _rechercherEtapeSuivante () ; 
_ordonnerResultat () ; 

} 

} 

private void _initialiser () {...} 
private void _positionnerDepartRecherche () {...} 
private int _rechercherEtapeSuivanteOptimale () {...} 
private int _rechercherEtapeSuivante () {...} 
private void _ordonnerResultat () {...} 



Operation SuiviMission::recevoirEvenement : 



Notre dernier exemple concerne la reception d'un evenement de mission dont le traitement 
revient au suivi de mission en cours. La reception d'un evenement s'execute toujours dans un 
meme contexte, mais donne lieu a des comportements totalement differents suivant le type 
d'evenement. 



Nous avons en effet distingue en analyse, les simples evenements des incidents d'etape et de 
trajet. Suivant leur nature, les incidents engendrent une serie de messages susceptibles de pro- 
voquer une reponse du repartiteur ou de recalculer les encours de mission. 

En raison de cette divergence de comportements, nous avons choisi de mettre en osuvre une 
strategie dont la hierarchie est documentee dans le diagramme de la figure 1 1 -23. 
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ContexteReceptonEvt 
reception ReceptionEvt 
survi : SurviMisswn {changeable} 
evt Eve ne men tM rssion (changeable) 



ContexteRecepttonEvt(rcpt ReceptonEvt) 
executerReception() 



«lnterface» 
RecepttonEvt 



executer(ctx CorrtexteRecephonEvt) 

-V A 



ReceptiontnadenlTrajet 



ReceptcnEvtSimple 



ReceptonlncidentEtape 



ReceptionRetardDepart 



ReceptionRetard 



ReceptJonClientAbsent 



ReceptionEtapeNonRespectee 



ReceptwnRefus 



ReceptionPanrteNonBtoquante 



ReceptionAnomaleLivralson 



ReceptionAnomalieEnlevement 



ReceptionAdfessetncorrecte RecepttonPaementNonEftectue 



Figure 11-23 : Structure des strategies de reception d'urt evenement 

La fabrication de la strategie depend du type de I'evenement de mission regu par le systeme. 
Pour cela, une fabrique catalogued isole et encapsule I'aiguillage switch que necessite la cons- 
truction des differents types de strategies. Le diagramme de sequence ci-dessous illustre la 
reception d'un refus client lors d'une etape. 

Une tois les mecanismes de la strategie definis, il convient bien entendu de decrire la methode 
executer(ctx) de tous les types de strategies possibles. On aura recours pour cela aux diagram- 
mes d'interactions et d'activites. 



Client 



sm : Suivi 
Mission 



: Fabrique 
ReceptionEvt 



ctx : Contexte 
ReceptionEvt 



rcpt : Reception 
Refus 



recevoirEvenement(EvenementMission) 



rcpt = receptionfEven^mentMission) 
> 



«create» ContexteReceptionEvt(ReceptionEvf 

} > 

setSuiviMission( sml 



setEvenementMissiiJn( EvenementMission) 



executerReception( } 



H executer( ctx) 



Figure 11-24 : Dynamique d'execution surla reception d'un evenement d'etape 
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Nous vous presentons ci-apres la structure du code correspondant a la fabrique catalogues 
chargee de construire les strategies. 



package SIVEx . metier . mission . evenementsMission ; 

public class FabriqueReceptionEvt () 

// mise en ceuvre du catalogue : 
Map _catalogue; 

ReceptionEvt instance ( Class cl) { 

/ / la classe de 1 ' evenement sert de cle : 
Object recept = _catalogue . get ( cl) ; 
if ( recept == null ) { 

// swith de fabrication en fonction des types d'evenements 
if ( cl .getName () .equals ( «IncidentTrajetRetardDepart») ) 

recept = new ReceptionRetardDepart () ; 
else if ( cl .getName () .equals («IncidentTrajetRetard») ) 

recept = new ReceptionRetard() ; 
else if ( cl .getName () .equals («IncidentTrajetPanneBloquante») ) 

recept = new ReceptionPanneBloquante () ; 
//etc... 

_catalogue .put ( cl, recept) 

} 



return (ReceptionEvt) recept ; 



} 



public void reception ( EvenementMission evt, SuiviMission sm) { 
ReceptionEvt strategie = instance ( evt . getClass () ) ; 

ContexteReceptionEvt ctx = new ContexteReceptionEvt ( strategie) , 
ctx . setSuiviMission ( sm) ; 
ctx . setEvenementMission ( evt); 
ctx . executerReception () ; 

} 



Conception de la couche de presentation 

La couche de presentation ou IHM se limite a la partie visible d'une applica- 
tion. Les environnements avec fenetrage (type Windows) ou pages HTML 
equipees de mecanismes reflexes en JavaScript, correspondent aux choix tech- 
nologiques les plus courants. Dans ces environnements, un utilisateur est face 
a trois grandes families de concepts. 

les fenetres (ou pages) et leur contenu qu'il voit, redimensionne, bouge et 

reduit, font partie des concepts visuels ; 
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les actions qu'il peut declencher et les changements d' aspects, font partie 
du comportement de la presentation ; 

les flux de donnees qu'il transmet via des listes de choix, des champs 
d'edition font partie de Fechange d' informations avec l'application. 

Concevoir ou documenter une couche de presentation revient a passer en 
revue ces trois aspects : le visuel, le comportemental et le fonctionnel. 

Grace aux environnements de developpement actuels, la conception d'une IHM 
s'effectue le plus souvent conjointement avec sa construction visuelle. Cette 
capacite est liee a F existence d' elements standard qui peuvent se composer a 
souhait pour former l'application de notre choix. Une IHM se caracterise 
egalement par la notion de fenetre ou de page qui represente un element inse- 
cable de presentation. Cette notion presente en effet une unite visuelle, compor- 
tementale et fonctionnelle, caracteristique tres utile pour organiser le modele 
UML de conception. Par ailleurs, une fenetre ou une page correspond a une vue 
de la couche applicative, comme nous l'aborderons au paragraphe suivant. 

II serait en fait rarement utile de documenter avec UML la structure statique d'une 
IHM, si ce n'est pour en etudier le comportement et les informations echangees. 
C'est en effet a la fois la force et la faiblesse des environnements modernes que de 
permettre la construction immediate de 1'IHM statique : force pour la productivite 
que cela procure au developpement, faiblesse pour l'apparente facilite qui masque 
les contraintes d' architecture d'une conception. On constate ainsi que les deve- 
loppeurs entreprennent la construction immediate des comportements et des flux 
de donnees, sans avoir pris la peine de denouer les mecanismes de comportements 
et d'echanges necessaires. Le manque de modelisation et de reflexion sur Finte- 
grite conceptuelle engendre frequemment un imbroglio de code difficile a relire et 
couteux a maintenir. Le manque de clarte est generalement lie a l'amalgame de 
responsabilites de niveau comportements, fonctionnels et applicatifs, au sein de la 
meme classe d'lHM. Nous allons justement etudier ici comment separer ces 
responsabilites pour gagner en lisibilite et en facilite de maintenance. 

La premiere etape de conception d'une IHM concerne la definition visuelle 
des fenetres ou des pages. L'existence d'un modele objet d'analyse permet 
d'influencer cette conception : a partir d'un diagramme de classes, un gene- 
rateur de code pourrait generer des fenetres ou des pages pour Faffichage et la 
saisie de chaque element du modele : 

une fenetre ou plusieurs pages pour chaque classe afin d'en editer les ins- 
tances : creation, modification des attributs et des relations, simple consul- 
tation et suppression ; 

une fenetre ou plusieurs pages pour certaines associations complexes afin 
d'en editer les liens. 

La figure 11-25 vous donne un apercu de cette idee en montrant des fenetres 
d'edition des sites et des parcours du reseau. L'equivalent en pages HTML est 
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aussi facile a imaginer ; notons cependant qu'il faut parfois doubler les pages 
car l'affichage et la saisie precedent de techniques HTML differentes. 




Figure 11-25 : Developpement d'une IHM calquee surle modele objet 



La conception d'une IHM provenant d'un modele objet n'est pourtant pas 
toujours aussi simple. Comme l'illustre le schema de la figure 11-26, 1THM 
doit en effet tenir compte des synoptiques attendus par les utilisateurs, or ces 
derniers font rarement partie du modele objet d' analyse. 




Figure 11-26 : Exemple de synoptique attendu mais non represents 
dans le modele objet d'analyse 
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L' utilisation d'UML pour documenter la structure statique d'un IHM permet 
de repertorier les fenetres ou pages puis d' identifier, le cas echeant, les 
composants reutilises d'une vue a 1' autre. Dans le diagramme de la figure 11- 
27, nous avons represente les fenetres de gestion du reseau ainsi qu'une liste 
deroulante ou drop list presentant une selection de choix de sites, utilisee a la 
fois dans la fenetre d' edition des parcours et dans la fenetre de selection des 
parcours. 



WEditeurSite 



WEditeurParcours 



WSelectionParcours 



depart 

1, 



WCarte 



arrivee 
1 



depart 
' 1 



DLstSelectionSite 



amvee 

K 



Figure 11-27 : Structure des classes graphiques d'edition du reseau 

La seconde etape de conception consiste a definir les comportements des fene- 
tres. Une modelisation UML s'impose alors pour concevoir la dynamique des 
IHM. En effet, a partir d'une fenetre ou d'une page, un utilisateur declenche 
des actions ou controle des activites. A chaque instant, la vue doit refleter ce 
qu'il a le droit ou non de faire, en desactivant des boutons, des champs, des 
menus ou tout autre element visuel de controle. 

La plupart des vues ont en fait un comportement de machine a etats ; le deve- 
loppement d'un diagramme d'etats est alors tres utile a la conception de leur 
comportement. D'autant plus que certains frameworks applicatifs, tels que le 
composant struts du projet Apache, realisent explicitement le deroulement 
d'une machine a etats en associant une page et une classe Java a chaque etat et 
en decrivant la dynamique des transitions separement dans un fichier XML. 

L etude de l'editeur de site permet d' identifier trois etats distincts ainsi que de 
trouver les attributs, les evenements et les actions associes a la fenetre ou a la 
page correspondante. 
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ouvrtr( site c 



mode nouveau 
l9Mha(CWS )7serrt this ^registrar 



enregistrer| modification = true &noir(EtCommuneCorrects ] 



ouvrlrf, site ) 



mode edrtion 



entry /positjonnerModeEdition 

enregistreit modification = true |/enregistrer 

touche( arl-S X modification = true ] /enregistrer 

charger / ouvrirSiteExistantr, edrtion) 

parcours / ouvnrSelect>onParcours( srteCourant edition) 



>de consultation 



entry / posrtionnerModeConsuttation 

charger I ouvnrSiteExistantf, consultation) 

parcours /ouvrirSetect)onParcours( srteCourant consultation) 

* 



chang,erMode( consultation ) ZnoDfierSiteEnConsuttationf srteCourant) 



cha ngerM ode( edition ) / not)fierSiteEnEdittort( srteCourant) 



Figure 11-28 : Bats de la fenetre Editeur de site 

En conception orientee objet, il est d'usage d'associer a chaque vue une classe 
dite controleur, dont Fobjectif est de piloter le comportement interactif avec 
l'utilisateur. Tandis que les evenements transmis par l'utilisateur sont regus et 
traduits techniquement par la fenetre, les activites et les etats concernent 
majoritairement le controleur. Si, en outre, le controleur est con5U a l'aide du 
design pattern etat, le code lie a 1'IHM devient extreme ment souple et facile a 
maintenir et ce meme pour les fenetres aux comportements les plus 
complexes. Le diagramme de la figure 11-29 montre la structure de la classe 
controleur ainsi que les etats qui en resultent. 



WEditeurSite 



modification : boolean 



nomEtCommuneCorrectsO : boolean 
positionnerMode(mode : TypeMode, estNouveau boolean 

0 fenetre 



«enum» 
TypeMode 



controleur 



CtrlEditeurSite 



enregistrer() 

vrtrSiteExistant(mode : TypeMode) 
ouvrirSelectionParcours(mode : TypeMode 
ouvrlr(slte : Site, mode : TypeMode) 
notifierSiteEn(mode : TypeMode) 
ouvrirNouveauSite() 



etat 



CMEditeurSiteEtat 



CtrlEditeurSiteEtatEdition 



QrlEditeurSiteEtatConsultation 



CtrlEditeurSiteEtatNouveat. 



Figure 11-29 : Structure Fenetre - Controleur- Etats, de la fenetre Editeur de site 
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Le controleur prend en charge les activites impliquant une coordination avec 
la couche de F application, tandis que la vue reste responsable des operations 
gerant F aspect graphique. 

La conception de FIHM se termine enfin par F etude des flux de donnees. 
Dans le modele vue-controleur que nous developpons ici, la vue communique 
avec Fimage memoire des donnees qu'elle affiche. Lors de la conception 
generique, nous avons qualifie de document (voir chapitre 9) cette image qui, 
tout en appartenant a la couche applicative, fait le lien entre le contenu affiche 
d'une vue et les objets metier. 

Si la couche application est responsable des documents, les vues de presenta- 
tion sont generalement responsables du transfert de format entre les informa- 
tions du document et celles qui sont affichees. Des operations d'acces sur 
toutes les donnees modifiables prennent en charge les transformations 
necessaires. Ces operations permettront au controleur de modifier la presenta- 
tion ou de recuperer les informations introduites par Futilisateur. Le 
diagramme de la figure 1 1-30 vous donne en final la structure de la vue WEdi- 
teurSite. 



WEditeurSite 

modification boolean 

nomEtCommuneCorrects() boolean 
positionnerModefmode TypeMode, estNouveau : boolean) 
setNomSite(nom : String) 
getNomSitef) : String 
setCommune(commune : Commune) 
getCommuneO Commune 
setModeAcces(lstAcces : ArrayList<String>) 
getModeAcces() : ArrayList<String> 
setRestaurations(lstRestau ArrayList<String>) 
getRestauration() ArrayList<String> 



Figure 11-30 : Atthbuts et operations de la fenetre Editeur de site 

Nous n'enchainerons pas le micro-processus de conception sur Fetape concer- 
nant les operations, car dans ce cas, la formalisation des operations de trans- 
fert de format est superflue. Mais, pour bien en comprendre Fimportance, 
imaginez les operations que necessiterait la vue representant le reseau sous 
forme cartographique (voir figure 11-26) : les coordonnees geographiques de 
chaque site doivent en effet etre converties en coordonnees image en fonction 
du niveau de zoom et de centrage choisi par Futilisateur. 



«struct» 
Commune 
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ETUDE DE CAS : CONCEPTION DE LA VUE D'EDITION D'UNE MISSION 

La fenetre d'edition et de consultation des missions est un peu plus sophistiquee. Elle corres- 
pond a la classe WEditeurMission. 

• La partie superieure comprend les attributs qui definissent une mission. Ces derniers sont 
obligatoirement renseignes lors de la creation d'une nouvelle mission. 

• La partie intermediaire represente a droite les attributs de la mission, a gauche les relations 
avec les ressources chauffeur et vehicule. 

• La partie inferieure donne les informations de chargement de la mission, le bouton Comman- 
des permet d'affecter des commandes via une fenetre complementaire. 

• Une barre d'etat restitue enfin I'etat de I'objet metier contenu dans la fenetre. 




Figure 11-31 : Fenetre d'edition d'une mission, telle que presentee dans la maquette d'lHM 

Le comportement de cette fenetre est sensiblement identique a la fenetre d'edition d'un site. Le 
menu Fichier permet d'acceder aux activites de niveau application : enregistrer, charger et crea- 
tion d'une nouvelle mission, tandis que le menu Etat accede aux activites de niveau metier : vali- 
der, annuler et recalculer pour forcer la mise a jour des attributs de chargement. L'lHM doit 
restituer I'etat metier de I'objet represente, ce qui influe sur les etats applicatifs de la fenetre 
WEditeurMission. 
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affecter Vehicule / 
affecter Chauffeur 
commandes / ouvr 
louche( Ctrl-S ) / *l 



:terChaufleuf 
»urCornmandes< edition) 
lregistrer 



recalculwl moaflcationMissions =true |/ recalculw 
(ouchef Ctrt-R | / "th.s recalculer 



eireQistrefl modrtlcation — true & 



we I 



f 


mode edition 


• 


entry 
^ 


posilion n e r Mode E dti on 


J 



mode consultation 


entry / positionnerModeConsultation 




validation / positionnerBatValidation 




depart / posttionnerBatEnCours 




commandes / ouvnrEoMeurCornmandest consults 




retour / postionnerBatExecute 





Figure 11-32 : Bats de la fenetre d'edition d'une mission 

La distribution des activites sur les classes Vueel Contrdleur ainsi que les operations de transfert 
des donnees aboutissent au diagramme de classes de la figure 1 1 -33. Les controles IHM corres- 
pondent aux associations et aux attributs derives du modele d'analyse sont introduits dans le 
document par des moyens complementaires, il n'y a done pour ces attributs que des operations 
set, permettant au controleur de positionner la valeur d'affichage. 



WEditeurMission 



modificationCommandes boolean 



positjonnerModeCreationlJ 
posilionnerModeEdition() 
positionnerModeConsultaDonO 
positjonnerEtatValidauonO 
posibonnerEtatEnCoursO 
positionnerEtatExecuteO 
setAgence(a Agence) 
setNoSemamefsem Semaine) 
getNoSemainej) Semaine 
setType(type : TypeMisaon) 
getType() : TypeMission 
setldentificationfid String) 
getldentificationO String 
setCommentaire(com : String) 
getCommentaireO String 
setDepartfdep : Date) 
getDepartO Date 
setChauffeur(ch Chauffeur) 
setVehicule(v : Vehicule) 
setRetour(ret Date) 
setPoids(p : Pods) 
setVolume(v : Volume) 
setDistanceld Distance) 



CtrlEdteur 



affecterVehicule() 

affecterChauffeurO 

ouvirEdrteurCommandesO 

recalculef() 

validerMission() 

annulerMissionO 

puvrirfm : Mission, mode ModeEdition) 



E 









CtrlEditeurMissionEtatNouveau | 


CtrlEditeurMissionEtatEdition 



Figure 11-33 : Structure Vue-Controleur-Bats de la fenetre Editeurde mission 
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LE DESIGN PATTERN OBSERVATEUR 

Le design pattern Observateur [Gamma 95] consiste a synchroniser des 
objets en minimisant les dependances qui devraient s'etablir entre eux. 
Chaque objet n'a cependant pas un role symetrique : nous y distinguons le 
sujet et les observateurs. 

Le sujet centralise les donnees et il est unique. II comprend des operations 
permettant aux observateurs d'acceder a ses donnees. 

L' observateur restitue les donnees du sujet auquel il est abonne, et plusieurs 
peuvent se synchroniser sur le meme sujet. 



Le diagramme de la figure 11-34 represente la structure nominale de F obser- 
vateur. 



Sujet 


s abonne a ^ 


Observateur 


0.1 



T 


sujet 






SujetConcret 


ObservateurConcret 


< 

0..1 



Figure 11-34 : Structure du design pattern Observateur 

La dynamique d'echange entre le sujet et ses observateurs abonnes s'etablit a 
partir d'une notification indiquant une modification du sujet. Ce dernier en 
avise ses observateurs qui questionnent en retour le sujet pour obtenir les 
informations necessaires a leur mise a jour. Le diagramme de communication 
de la figure 11-35 decrit une notification concernant un sujet et ses deux 
observateurs. 



Client 



1 modifier 

2 notifier 



ob1 : ObservateurConcret 



2.1 mettreAJour 




: SujetConcret 



2.1.1 getlnformations 
2.2 mettreAJour 




2.2.1 getlnformations ob2 : ObservateurConcret 



Figure 11-35 : Dynamique du design pattern Observateur 
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L'observateur est egalement connu comme modele document- vue : termino- 
logie que nous avons justement retenue lors de la phase de conception gene- 
rique de la couche de F application. 

Dans ce cadre, chaque fenetre ou page de presentation implemente une vue 
(observateur) et s'abonne par ce biais aux modifications du document associe. 
De leur cote, les documents ne connaissent des fenetres ou des pages que leur 
interface Vue. Par cet artifice, nous conservons l'independance logicielle de la 
couche de 1' application vis-a-vis de la couche de presentation, bien que les 
mecanismes de rafraichissement leur imposent une collaboration etroite. 

Ce design pattern est integre a Java au travers des classes Observable et 
Observer du package Java.util. Par souci de standardisation, la conception du 
framework de la couche de l'application n'a pas manque d'integrer ces classes 
pour concevoir les notions de Document et de Vue. 



Java::util 



Observable 



o- 



<<lnterface» 
Observer 



Document 



sauvegarderQ 



0..1 



«lnlerface>> 
Vue 



ouvrirO 
fermerO 



Figure 11-36 : Utilisation des definitions standards de Java 



Conception de la couche Application 

Le role de la couche de l'application consiste a piloter les processus d'interac- 
tions entre l'utilisateur et le systeme. Cette notion peut paraitre abstraite, mais 
il s'agit generalement de mettre en ceuvre toutes les regies necessaires au 
maintien d'une application coherente et a roptimisation des echanges client/ 
serveur et/ou des requetes http. 

De maniere plus precise, les mecanismes d'une application assurent : 

1' existence de differentes fenetres ou pages synchronisers sur les memes 
donnees ; 

la coherence entre les objets distribues et les multiples fa5ons de les repre- 
senter au travers des IHM ; 

F optimisation des chargements au niveau des servlets pour un deploiement 
en client leger ou sur le poste client pour un deploiement client/serveur ; 
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le respect des habilitations des differents acteurs ; 

l'obligation pour l'utilisateur d'abandonner ou de mener jusqu'au bout un 
changement commence ; 

la mise en ceuvre des concepts applicatifs : typiquement les sorties de rap- 
ports sur imprimante. 



Pour toutes ces capacites, la conception d'une application s'appuie sur la 
definition des documents representant en fait F image memoire des fenetres ou 
des pages de presentation. Par definition, il existe un document par vue de 
1' application. Chaque document definit ensuite les operations permettant aux 
pages ou fenetres d'acceder aux informations necessaires a Faffichage. 



La synchronisation concerne la relation entre un document et ses vues, mais 
egalement entre plusieurs documents. Un objet Site peut etre a la fois visible 
via la page d'edition d'un site, mais egalement par F intermediate d'une 
representation geographique. Le document associe a la carte geographique est 
qualifie de document composite, en ce sens qu'il rapporte implicitement 
Finformation de plusieurs documents Site et Parcours. En consequence, le 
document composite devient implicitement un observateur d'autres docu- 
ments. Cette caracteristique se traduit par des relations d'agregation entre 
documents, comme illustre dans le diagramme de la figure 1 1-37. 



«lnterface» 


c 


Vue 





<3 t> ^ 



«lnterface» 



WEditeurParcours 





WEditeurSite 




WCarte 



documeni 



Document 



document 



DocSite 



DocParcours 



site 



parcours 



document 



DocCarte 



Figure 11-37 : 



Structure du document composite associe a une carte geographique 
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Le diagramme de communication de la figure 11-38 montre comment la 
modification d'un site se propage parallelement a la fenetre d' edition et a la 
carte. 



Client 



1 . notifier 
> 



: DocSite 



site 



1 .2 update 



V 



observer 



1.1 mettreAJour 
> 



| 1.2.1 



document <g vue 

1.1.1 getlnfo... 



getlnfo... 



: WEditeurSite 



1.2.2 mettreAJour 



: DocCarte 



document 



: WCarte 



1.2.2.1 getlnfo... 



Figure 11-38 : Propagation d'un rafraichissement entre documents et vues 

On trouve generalement des documents composites lorsqu'il faut representer 
des cartes, des synoptiques, des schemas, des courbes, des tableaux, des arbo- 
rescences ou des diagrammes. Une liste d'objets presente egalement le 
comportement d'un document composite lorsque celle-ci doit reagir au chan- 
gement d'un libelle caracteristique ou a la suppression d'un objet. 

L' optimisation des echanges consiste a memoriser ce qui a deja ete charge, de 
telle sorte que l'application puisse minimiser les appels aux objets distribues. 

Charger un document revient done a demander le transfert des entites corres- 
pondantes ; la memorisation de ces chargements s'effectue a l'aide d'un cata- 
logue de references OID. A des fins d' optimisation, le catalogue est organise 
en sous-catalogues, classes par nom de classe, qui retrouvent eux-memes les 
objets par OID. Comme le montre le diagramme de la figure 11-39, les attri- 
buts qualificatifs d'UML servent a specifier ces cles de rangement. 



CatalogueDeClasses 
{singleton} 



1 



omClasse : String 



CatalogueDObjets 



charger(oid : OID) : Object 



oid :OIDO 



Document 



Figure 11-39 : Structure du referencement des documents 
charges dans la couche application 
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Le diagramme precedent schematise la structure du catalogue de reference des 
documents. L' interface EntComposant represente toutes les entites provenant 
des composants distribues. Le chargement d'une entite est done systematique- 
ment soumis au catalogue, de maniere a retrouver les donnees precedemment 
chargees. 

Si cette technique minimise les echanges sur le reseau, elle en complique le 
protocole de synchronisation. II faut en effet s' assurer par d'autres meca- 
nismes que les donnees precedemment chargees n'ont pas ete modifiees paral- 
lelement par une autre application. Cependant, nous arreterons la la reflexion 
de conception car ce n'est pas le but de l'ouvrage ; sachez que ce probleme lie 
a l'integrite des donnees distributes peut etre gere de differentes manieres 
avec differents couts de developpement. Nous conseillons dans ces cas de 
proceder a une analyse de la valeur et de fournir uniquement le mecanisme de 
synchronisation necessaire, sans rechercher de sophistications couteuses. 

Nous traitons enfin la coherence des processus de 1' application en recourant 
au design pattern Commande. Cette technique nous permet en effet de garantir 
un comportement homogene face aux actions de l'utilisateur, en termes de 
traces produites et de verification d'habilitations. Une commande complexe 
peut enchainer des sous-commandes et assurer l'atomicite transactionnelle des 
interactions de l'utilisateur, a savoir que toute interruption d'une sous- 
commande implique l'interruption de la commande complexe. 



LE DESIGN PATTERN COMMANDE 

Le design pattern Commande [Gamma 95] consiste a reifier un groupe 
d'operations afin de pouvoir les traiter comme les ressources d'une applica- 
tion. On peut memoriser de la sorte les demieres commandes effectuees par 
un utilisateur ou bien leur associer dynamiquement une sequence de touches 
clavier. 

La structure du design pattern Commande inclut les elements suivants (voir 
figure 11-40) : 

une interface d' execution generique (appelee ici « commande applica- 
tive », CommandeApp pour la differencier de l'objet metier Commande) ; 

un recepteur correspondant a l'objet porteur de 1' operation effectivement 
executee par la commande ; 

un invocateur charge de gerer et d'enchainer l'execution des commandes. 
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Invocateur 


O > 


«lnterface» 
Comma ndeApp 








executerQ 



Recepteur 



actionQ 



CommandeConcrfite 



Figure 11-40 : Structure du design pattern Commande 



Ce design pattern permet de : 

standardiser l'execution d'une meme famille d'operations, en produisant 
des verifications d'habilitation et des traces d' execution ; 

controler le deroulement et Fatomicite d'une action composee d'un 
enchainement de sous-actions. 



Nous illustrons ces deux avantages dans la conception des commandes 
d' edition d'une mission. Mais ce design pattern permet aussi de : 

differer l'execution d' actions lorsque F invocateur doit assurer, par exem- 
ple, la disponibilite d'un equipement tout en maintenant la disponibilite de 
F interface utilisateur ; 

memoriser les commandes executees et d'offrir le cas echeant le service de 
defaire {undo) ou de reprise de crash ; 

associer dynamiquement des actions a des controles de F utilisateur, pour 
realiser des macros ou bien pour personnaliser des touches du clavier. 

Dans notre conception, Finterface CommandeApp est potentiellement 
composee d'autres commandes. Les commandes representant par ailleurs les 
actions de Futilisateur sur une application, le recepteur est naturellement le 
document sous-jacent a la vue d'oii est declenchee Faction. L'invocateur coor- 
donne enfin les commandes, les documents et les informations de Futilisateur 
connecte pour generer les traces et verifier les habilitations. 

Le diagramme de communication de la figure 11-41 resume les roles et 
responsabilites des differents objets intervenant dans l'execution d'une action 
de Futilisateur. 
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1.1.2 poster(cmd) 



: Fenetre 



: Utilisateur 

Presentation represente 



1.1.1 «create» (document) 



1.1.2.1 tracerlnvocation 
1.1.2.2verifierHabilitation 
1.1.2.4tracerRetour 



Application 



document 

recepteur 



cmd iCommandeApp 



1.1.2.3.1 action 



1 .1 .2.3executer 



: InvocateurApp 

{singleton} 



Figure 11-41 : Dynamique d'echange d'une commande 
entre les couches presentation et application 

Dans la couche de presentation : 

la fenetre ou la page transforme les evenements de F utilisateur en action, 
elle restitue par ailleurs les informations du document si ce dernier a ete 
modifie ; 

le controleur centralise les actions declenchees depuis 1'IHM, il cree la 
commande correspondante a Faction et la place en file d' execution aupres 
de Finvocateur applicatif ; 

Dans la couche de F application : 

Finvocateur execute les commandes et, suivant un protocole standard, 
assure les traces et les verifications d'habilitation ; 

la commande encapsule Faction sur un document et permet de les enchai- 

ner dans une meme unicite d'actions de Futilisateur ; 

le document encapsule les donnees necessaires a la presentation d'une 

fenetre ou d'une page. II gere la coherence des differentes vues sur ses 

donnees et prend en charge les operations necessaires a F execution des 

commandes. 



© 

Note 



On retrouvera le concept de commande au travers de la classe Action du fra- 
mework Struts. 
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ETUDE DE CAS : CONCEPTION DU DOCUMENT D'EDITION 



La conception des documents est, en termes d'attributs et d'operations, le reflet des vues de 
presentation. 



«lnterface» 
Document 



enregistrer() : boolean 
ouvrir(oid : OID) 
fermerO 



DocEditeurMission 



oid : OID {frozen} 
agence : OID {frozen} 
noSemaine : Semaine {frozen} 
type : TypeMissbn {frozen} 
identification : String {frozen} 

nmentaire : String {changeable} 
depart : Date {changeable} 
chauffeur : OID {frozen} 
vehicule : OID {frozen} 
retour : Date {readonly} 
ooids ' Poids (readonly) 
"volume : Volume {readonly} 
distance : Distance {readonly} 



getAgence() : Agence 
getVehiculeO : Vehicule 
getChauffeurO : Chauffeur 
affecterChauffeur(chauffeur : OID) 
affecterVehicule(vehicule : OID) 
affecterMission(mission : OID) 

rMission(mission : OID) 



Figure 11-42 : Definition du document d'edition de mission 

La conception des classes de type document doit prendre en compte les etats applicatifs, ce qui 
permet d'affiner ses operations par I'application du design pattern Etat. On se servira done ici de 
la technique deja presentee dans le paragraphe consacre a la conception des classes. 



en modification 



affecterCmd( cmd ) / verifierTonnage 

atfecterVehicule( v ) / verifierTonnage: verifierQualificatoon 

affecterChauffeut( ch ) / verifierQualification 



creer( type, nom. 



ouvrir( nom ) / 



hDepart) 

modifier! < 1 h avant depart 
valider / mission sauvegarder 



Figure 11-43 : Conception des etats du document d'edition de mission 
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II convient dans un second temps de concevoir les commandes associees au 
document. II n'y aurait bien entendu aucun interet a traiter toutes les actions 
possibles de l'utilisateur, c'est pourquoi nous prenons, a titre d'exemple, la 
commande applicative d'affectation d'une Commande metier a une mission 1 . 
Le processus consiste a ouvrir une vue permettant 1' edition des objets 
Commandes de la mission, puis a iterer sur une ou plusieurs selections de 
l'utilisateur, avant de terminer par une validation ou un abandon. La 
commande applicative pilote done elle-meme d'autres sous-commandes qui 
peuvent interrompre la transaction en cours. Ce type d'enchainement illustre 
parfaitement ce que nous appelons un processus applicatif. 



CmdAffectationCommande 



ouvrirEditeurCommandesMisson 



fefmerEditeurCommandesMission 



a nec let u om ma na es 







[ abandon ] 

1 



CmdAjoutCommandeMission 



! CmdValidationSelection 



> ouvrirSelectonCommande 



raputerSeleaion 



fermetSeleclionCommande 



-else 



slockerSelection 



Figure 11-44 : Processus d'affectation d'objets Commande a la Mission 

Un diagramme d'activite dote de couloirs de responsabilite (ou partitions) constitue la formalisa- 
tion la plus appropriee pour representer ce type d'enchainement. L'apercu que vous en donne la 
figure 11-44 montre la separation des responsabilites et I'imbrication des declenchements entre 
les commandes applicatives. 



Conception de la couche metier distribute 

Maintenant que vous avez un bon aper5U de la conception des couches de 
presentation et de 1' application, nous allons aborder 1' etude de la couche 
metier. Conformement aux preconisations du style d' architecture 3 -tiers, la 
couche metier distribue ses interfaces via le middleware RMI. 



1 .11 se trouve que nous appliquons le Design Pattern commande aux concepts metier de Missions 
et de Commande. Pour ne pas risquer de confondre les deux notions une Commande commencant 
par une majuscule fait reference au concept metier. 
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Une conception simpliste de la distribution consiste a projeter toutes les 
classes de la couche metier en interfaces EJB. Cette approche naive a cepen- 
dant les inconvenients suivants : 

toute consultation ou modification sur les attributs d'une classe metier 
entraine un echange de services RMI/IIOP (protocole utilise par les EJB). 
On imagine le volume de transactions necessaires a l'edition d'une mis- 
sion comportant une dizaine d' attributs et les temps de reponse qui en 
decoulent ; 

toutes les instances en cours d'edition dans l'application donnent chacune 
lieu a une tache et a une connexion d'echanges RMI/IIOP. Pour un sys- 
teme de Fampleur de SIVEx, cela exige des ressources CPU, memoire et 
socket tres importantes de la part des serveurs ; 

toutes les instances distributes ont une adresse HOP et saturent le gestion- 
naire de references. 

Pour eviter ces handicaps egalement valables pour CORBA, DCOM ou RMI, 
il est d' usage de concevoir une distribution en tenant compte des principes 
suivants. Bien entendu, ces principes ne sont pas a prendre en depit du bon 
sens. 

une classe represente un ensemble d' attributs insecables pour la distribu- 
tion. Dans ce cas, il vaut mieux echanger en une seule transaction l'ensem- 
ble des informations d'une instance ; 

lorsque 1' exploitation d'une classe ne concerne que des aspects CRUD 
(Create, Retrieve, Update & Delete) et que la frequence d' interactions 
avec le serveur est faible (inferieure a 20 transactions par minute), il est 
d'usage de ne definir qu'un seul objet distribue par classe. Cet objet, de 
type EJB session et non EJB entity, represente successivement differentes 
instances dont les etats sont conserves au travers des structures d' informa- 
tions echangees. 

Ces principes respectent les contraintes qu' impose un middleware objet : 
reduire la frequence des transactions, le nombre de references et la multiplica- 
tion des taches sur le serveur. Pour appliquer ces conseils, nous utilisons les 
deux types d'objets distribues de la norme EJB. 

Les premiers, de type session, constituent les instances qui echangent les 
instances par structure de donnees ; nous en avons concu le concept au tra- 
vers d'une interface capable de fournir un OID et un ensemble de cles 
metier, necessaires a 1' identification par les utilisateurs. 
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«lnterface» 
ObjetSession 



{EJB = session} 



oid() :OID 

cleMetier( codeDonnee : String) : String 



Figure 11-45 : Definition de /'interface entite de composant dans la conception generique 

Les seconds, de type entity, correspondent aux objets que Ton desire reel- 
lement representer avec un etat distribue. Chaque objet session, echange 
par valeur, peut etre associe a F entite qui correspond au me me objet metier 
distribue et qui peut etre utilise conjointement suivant les deux modes, 
dans le cas ou on attend une forte frequence de consultation sur une meme 
instance de cette classe. Le diagramme ci-apres montre la structure d'une 
entite d'une session couplee. On recourt a une technique de representation 
UML souvent utilisee en conception detaillee, mais qui n'est pas comple- 
tement conforme a UML : nous savons en effet qu'une interface ne peut 
comporter ni attribut, ni association. Les attributs et les associations de 
l'interface representent en fait les operations d'acces (get et set) qu'ils 
generent par application des regies de conception des attributs et des asso- 
ciations que nous avons etudiees dans ce chapitre. 



«lnterface» 
ObjetEntite 



{EJB = entity} 



refSessionld [1 ..*] : long {changeable} 
conteneur : URL {frozen} 



oid() : OID {remote} 

reserverfsessionld : long) : boolean {remote} 
liberer(sessionld : long) {remote} 
desactiverfsessionld : long) {remote} 



{frozen} 


«lnterface» 


> > 

1 


ObjetSession 



Figure 11-46 : Definition d'une entite couplee a un objet session 
au niveau de la conception generique 

La conception de la couche metier consiste a identifier les objets entites et 
sessions qu'il convient de developper au vu des classes et des operations 
metier a distribuer. 



Le concept d'objets distribues pose egalement le probleme de la distribution 
des liens d'un graphe d'objets. Pour cela deux techniques s'opposent : 

soit les objets sont distribues unitairement, et la demande d'un objet lie ou 
de sa reference declenche une nouvelle demande de transaction. Cette pra- 
tique convient bien a 1' edition d'objets metier telle que celle d'une mis- 
sion : lorsque l'utilisateur veut obtenir des informations sur le chauffeur 
associe a la mission en cours d' edition, une nouvelle transaction rapporte 
l'entite de chauffeur correspondante dans le contexte memoire de la servlet 
ou de 1' application cliente ; 
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soit un graphe complet d'objets lies est prealablement charge dans le con- 
texte memoire de la couche de presentation. Cette technique s'utilise de 
preference pour realiser la presentation de documents composites, a savoir 
l'edition d'une carte du reseau qui requiert le rapatriement des informa- 
tions de tous les sites et parcours a afficher. La difficulte consiste cepen- 
dant a definir la frontiere du graphe, de sorte qu'il n'est peut etre pas 
necessaire de rapporter tous les sites et parcours d'Europe, si la carte ne 
concerne que la region Cote d' Azur. 

Pour repondre a cette problematique de conception, nous avons introduit le 
design pattern Reference futee, inspire du smart pointer : Fidiome de 
programmation C++ [Lee 97]. La gestion des liens par reference futee va en 
effet permettre le maintien des objets lies dans le contexte memoire de 1' appli- 
cation tout en masquant au developpeur la decision de chargement et en assu- 
rant que seul ce qui sera reellement utilise sera transfere sur le reseau. 

"| LE DESIGN PATTERN REFERENCE FUTEE 

Ce design pattern a pour objectif de realiser la navigation au travers d'une 
association, en masquant les mecanismes de mise a jour du graphe d'objets en 
memoire. Cette technique est motivee par le besoin de synchroniser deux gra- 
phes d'objets qui, residants dans deux espaces memoire distincts, sont image 
Fun de 1' autre. C'est le cas lorsque Ton souhaite distribuer un graphe d'objets, 
le graphe existe a la fois sur le serveur et sur le client. Cette technique peut 
egalement etre utilisee entre un graphe d'objets persistants et son equivalent 
dans la base de donnees. 

Vouloir charger une representation du graphe dans le contexte client ne 
signifie pas forcement charger le graphe tout entier. Cependant, l'utilisateur 
peut demander a naviguer sur une association qui sort des limites de ce qui a 
ete prealablement charge. La reference futee s'occupe alors du chargement de 
l'instance demandee, et masque au developpeur les mecanismes pour se 
synchroniser avec l'image. 

La structure de la reference futee est detaillee dans le diagramme suivant. Une 
classe Reference vient s'immiscer dans la relation entre le client et son sujet. 



ReferenceAbstraite 


sujet 
> 


«lnterface» 
SujetAbstrait 


oidSujet {frozen} 


0..1 


oid {frozen} 


getSujetQ : SujetAbstrait 


qetlnstance(oid) : SujetAbstrait 





A 



Client 


1 


Reference 




♦ > 





SujetConcret 



Figure 11-47 : Structure du design pattern Reference futee 
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Le mecanisme mis en jeu par la reference futee est analogue au mecanisme 
d'un singleton. Le diagramme de collaboration de la figure 1 1-48 en montre la 
dynamique de declenchement. 



: Client 


> 


: Reference 





-lien cree 



sujet 



s : SujetConcret 



1 .1 [sujet = null] s = getSujetf oidSujet) 



: SujetConcret 



1.1.1 «create» 
> 



Figure 11-48 : Dynamique du design pattern Reference futee 

La reference futee nous permet ainsi de distribuer les associations par l'utilisa- 
tion des objets sessions ; le diagramme ci-apres illustre son utilisation sur la 
classe Parcours dans la mesure oil la classe PtrSite realise une reference futee 
sur les sites de depart et d' arrivee du parcours. 





«lnterface» 




SessionSite 




{EJB = session} 


oidSite : 


OID 


getSiteQ 


: EntSite 



depart 



«lnterface» 
EntiteParcours 



{EJB = entity} 



temps : Duree 
distance : Distance 
itineraireAller : String 
itineraireRetour : String 
peages : ArrayList<String> 



Figure 11-49 .Application d'une reference futee aux liens entre Site et Parcours 

Nous allons maintenant recapituler tous les elements de conception que nous avons 
introduits pour realiser une couche metier distribute au travers de 1' etude de cas. 



ETUDE DE CAS : CONCEPTION DE LA CATESORIE METIER:: MISSION 

La distribution des classes metier tient compte des resultats de la conception generique pour 
organiser techniquement la distribution, mais egalement des resultats de la conception prelimi- 
naire pour structurer les services distribues en interfaces. Dans ce cadre, des EJB sessions dis- 
tribuent des structures de donnees pour mettre en ceuvre les mecanismes CRUD, mais realisent 
en plus les operations distributes que I'on a deja formalisees sous forme d'interfaces en phase 
de conception preliminaire (voir chapitre 10). 

Le diagramme de la figure 1 1 -50 schematise la structure des classes de distribution pour la cate- 
gorie Mission. Nous y trouvons un objet session des missions qui est principalement dedie a leur 
edition CRUD et une classe d'entite des suivis de mission, servant a distribuer I'etat d'avance- 
ment d'une mission. Le suivi de mission implemente d'une part un etat distribue, mais impose 
d'autre part des mises a jour frequentes pour les repartiteurs et pour les clients en recherche 
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d'information sur I'encours de leurs commandes. Nous prevoyons en consequence qu'un objet 
session soit egalement construit pour le suivi de mission. 



«lnterface» 
ISuiviMission 



invalided) 

reordonnerEtapesQ 

reestimer() 

arriveeEtape() 

depart Etape{) 

signalerAnomalie() 

signalerPanne() 

finMissionf) 



Provenant de la 
categorie Mission 



Provenant de la 
conception generique 



c<lnterface» 
ObjetEntite 



{EJB = entity} 



«lnterface» 
ObjetSession 

{EJB = session} 



«lnterface> 
EntiteSuiviMission 

{EJB = entity} 



< 



«lnterface» 
SessionSuiviMission 

{EJB = session} 



«lnterface» 
SessionMission 



{EJB = session} 



<lnterface» 
IMission 



creerTournee() 
creerTraction() 
iffecterCommandeQ 
affecterChauffeur() 
affecterVehiculeO 
valider() 
invalider() 
signalerDepart() 
^7 completer!" rajet() 

desaffecterRessourcesO 
desaffecterCommandeQ 



Figure 11-50 : Structure de distribution de la categorie Metier:: Mission 

La conception detaillee d'une distribution ne s'arrete pas a la definition de sa structure. L'ensemble 
des operations distributes definissent egalement des signatures necessitant le passage d'informa- 
tions autres que celles contenues dans la structure d'instance representant la classe. Nous devons 
done y ajouter la definition de toutes les structures de donnees correspondant aux parametres des 
operations. 



Conception du stockage des donnees 

La realisation d'un stockage des instances varie suivant le mode de stockage 
retenu. Dans tous les cas, la realisation d'un modele objet facilite la mainte- 
nance des donnees stockees. II existe aujourd'hui plusieurs modes de stockage 
possibles. 

Le systeme de fichiers est actuellement le moyen le plus rudimentaire de 
stockage. Avec le mecanisme de serialisation, Java a fortement simplifie la 
technique de stockage d'objets dans des fichiers. Le stockage en fichiers 
ne coute done pratiquement rien. Cependant, il ne permet que de lire ou 
d'ecrire une instance par des moyens externes a 1' application et il n'a 
aucune capacite a administrer ou a etablir des requetes complexes sur les 
donnees. 

La base de donnees relationnelle ou SGBDR est un moyen deja plus 
sophistique. II existe aujourd'hui une large gamme de SGBDR repondant a 
des besoins de volume, de distribution et d' exploitation differents. Le 
SGBDR permet d' administrer les donnees et d'y acceder par des requetes 
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complexes. C'est la technique la plus repandue, que nous avons retenue 
pour SIVEx. Notre conception aborde done, a la fin de ce paragraphe, les 
principes de rapprochement objet-relationnel. 

La base de donnees objet ou SGBDO constitue la methode la plus elaboree 
de toutes. Cette technique elude la conception d'un stockage des donnees 
puisqu'elle permet de stocker et d'administrer directement des instances 
de classe. Cette technique n'a pourtant pas connu un grand succes sur le 
marche des bases de donnees. 

La base de donnees XML ou SGBDX est un concept emergeant qui 
repond au besoin croissant de stocker des documents XML sans risque 
d' alteration de ces derniers. Dans le cadre de developpement oriente objet 
qui nous occupe, cela signifierait une translation intermediate entre nos 
objets Java et un format XML. Bien que certains composants standards 
(JDO ou Xerces) facilitent ce travail, il ne nous a pas paru opportun de 
recourir a ce type de technologie pour SIVEx. 

La conception du stockage des donnees consiste a etudier sous quelle forme 
les instances sont sauvegardees sur un support physique. Elle s'accompagne 
egalement d'une conception de la couche d'acces aux donnees, qui explicite 
comment se realise la transformation du modele de stockage en modele 
memoire. On peut citer ici le composant open source Castor/JDO qui foumit 
la conception tres complete d'une couche d'acces aux donnees, et tout 
particulierement dans un cadre objet-relationnel. 




1 PASSAGE DU MODELE OBJET AU MODELE RELATIONNEL 



Etude L'utilisation d'un SGBDR impose un changement de representation entre la 
structure des classes et la structure des donnees relationnelles. Les deux 
structures ayant des analogies, les equivalences [Blaha 97] exprimees au 
tableau 11-1 sont utilisees pour en realiser le rapprochement. 

Une classe definit une structure de donnees a laquelle souscrivent des instan- 
ces ; elle correspond done a une table du modele relationnel : chaque attribut 
donne lieu a une colonne, chaque instance stocke ses donnees dans une ligne 
(T-uplet) et son OID sert de cle primaire. 

Certains attributs de type complexe ne correspondent a aucun des types de 
SQL ; on rencontre frequemment ce cas pour les attributs representant une 
structure de donnees. Un type complexe peut etre confu ; 

soit avec plusieurs colonnes, chacune correspondant a un champ de la 
structure ; 

soit avec une table specifique dotee d'une cle etrangere pour relier les 
instances aux valeurs de leur attribut complexe. 
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Modele objet 


Modele relationnel 


Classe 


Table 


Attribut de type simple 


Colonne 


Attribut de type compose 


Colonnes ou cle etrangere 


Instance 


T-uplet 


OID 


Cle primaire 


Association 


Cle etrangere ou Table de liens 


Heritage 


Cle primaire identique sur plusieurs tables 



Tableau 11-6 : Equivalences entre les concepts objets et relationnels 

Le diagramme suivant (figure 11-51) illustre la conception du stockage de la 
classe Commande dans la table TblCommande correspondante. UML definit 
specifiquement un stereotype table pour representer la table d'un schema rela- 
tionnel. Nous avons ajoute le stereotype join pour exprimer les jointures que 
definissent les cles etrangeres entre tables. 



Commande 



refCommande : String 
adresseEnlevement : Adresse 
adresseLivraison : Adresse 
modeLivraison : ModeLivraison 
nbColis : int 

poidsTotalE slime : Poids 
matiereDangereuse : Boolean 
modePaiement : ModePaiement 
daleEnlevementPrevu : Date 
dateLivraisonPrevue : Date 



«table» 
TblCommande 



oid : Varchar(32) 

idAdresseEnlevement : Varchar(32) 
idAdresseLivraison : Varchar(32) 
modeLivraison : Varchar(8) 
nbColis : Integer 
poidsTotalEstimeValeur : Float 
poidsTotalEstime Unite : Varchar(3) 
matierDangereuse : char(1) 
idModePaiement : Varchar(32) 
daleEnlevementPrevu : Date 
dateLivraisonPrevue : Date 



«join» 
/ 



«table» 
TbIAdresse 



«join» 
\ 

k_ 



«table» 
TbIModePaiement 



Figure 11-51 : Conception du stockage de la classe Commande avec une table relationnelle 



II est a noter que le schema relationnel ne permet pas de differencier les asso- 
ciations des agregations et des compositions. Quel qu'en soit le type, les rela- 
tions correspondent en effet a une cle etrangere lorsque la multiplicite le 
permet. Une association multiple, plusieurs a plusieurs, necessite en revanche 
la definition d'une table de liens supplementaire. Cette derniere stocke des 
couples de cles etrangeres provenant de chacune des deux classes de F associa- 
tion. Le diagramme de la figure 11-53 schematise la conception des associa- 
tions, simple et multiple, de la classe EnCoursDeCmd. 
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EnCoursDeCmd 



0..1 



passe par 



{ordered} « 



Agence 



«table» 
TbIEnCoursDeCmdAgence 



oidEnCoursDeCmd : Varchar(32) 
oidAgence : Varchar(32) 
noOrdre : Integer 



JLi_ 



«join» 



Comma nde 



«table» 
TbIEnCoursDeCmd 



«join» 

i 
I 



«join» 
25l 



«table» 
TbIAgence 



«table» 
TblCommand< 



Figure 11-52 : Illustration d'une table servant a stacker une association multiple 

La relation d' heritage se definit par le partage du meme OID entre les tables 
provenant d'une meme hierarchie de classes. Dans l'exemple de la figure 1 1- 
53, une mission de tournee stocke ses donnees dans les tables TblMission et 
TblMissionDeTournee, tandis qu'une traction conserve les siennes dans les 
tables TblMission et TblTmction. Dans les deux cas, c'est une jointure sur les 
tables appropriees qui permet de reconstituer une instance complete. 



Mission 



MissionDeTournee 



«table» 



ft 



«join» 



«join» 



MissionTraction 



J 



«table» 
TblMissionDeTournee 



«table» 
TbITraction 



Figure 11-53 : Illustration du stockage d'une relation de generalisation 



ETUBE t>E CAS : CONCEPTION bU STOCKAGE bES CLASSES MISSION 

II s'agit ici de definir les tables correspondant a la classe Mission et a ses specialisations. Une 
fois comprise, la conception du modele relationnel ne pose aucune difficult. C'est pourquoi les 
generateurs de code SQL fournis par les outils CASE apportent generalement une aide facile a 
mettre en ceuvre et appreciable. Dans le diagramme suivant, nous avons simplement applique 
les techniques exposees au paragraphe precedent. 
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<<table>> 
TblAgence 



\ 

«join» 





«table» 
TbIMission 


«join» 


oid : Varchar(32) 
commentaire Varchat(256) 
dateDepatt Date 
oidAgence Varchar(32) 
oidVehicule Varchar(32) 
oidChauffeut Varchar(32) 


«join» 


" «join» 





«table» 



TblVehicule 



«join>: 



«join» 



TWTraction 
Old Varchar(32) 
OidAgence Varchar(32) 



JT 

i 

«join» 
I 

I 



<<table>> 
TblTractJOn_Commande 



oidTracbon Varchar(32) 
oidCommande Vafchar(32) 



\ 




«table» 
TbIEtape 


«table» 




Tbl Mission DeTournee 




OldMissionDeTournee Varchar(32) 
oidCommande Varchar(32) 
nbColisEffectif Integer 
montantPaement_Montant Float 
montantPaBment_Devise :Varchar(3) 
idModePaiement Varchar(32) 
idAdresse Varchar(32) 
idContact Vatchar(32) 


oid : Varchar(32) 
typeDeTournee Varchar(3) 


^ «join» 








J 


' 1 ' 




<join» 


1 
■ 

«join» 



■<aoin» 



^ 

«table» 
TblCommande 



<<joint» 



TbIModePaiement 



type Varchar(8) 
noReferece Varehat(24) 



Figure 11-54 : Structure des tables relationnelles pour stocker les missions 



Nous avons maintenant termine 1' etude de la conception detaillee et aborde 
tous les aspects du developpement depuis 1' analyse jusqu'a la conception 
detaillee. Vous pouvez mesurer ici le volume d' informations relativement 
important que produit la phase finale de conception detaillee, et comprendre 
de ce fait l'importance que nous accordons a la decomposition en categories et 
en sous-systemes ; cette decomposition permet en effet de structurer, d' orga- 
niser, et done de faciliter la maintenance du modele. 

Une fois le modele de conception termine, il peut etre encore opportun de 
developper le modele de configuration logicielle. II s'agit de preciser 
comment les differents produits doivent etre assembles a partir des classes, 
des interfaces et des tables du modele logique. 
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Developper la configuration logicielle 

Rappelons que la conception preliminaire a defini une structure de configura- 
tion logicielle en packages ou sous-systemes. C'est lorsque toutes les classes 
sont detaillees a un niveau proche du code que chaque sous-systeme de confi- 
guration logicielle peut etre defini. 

La technologie Java a grandement simplifie cette derniere etape de conception 
puisque a chaque classe de conception correspond par defaut une classe Java, qui 
est elle-meme codee dans un fichier source identifiable par le nom de la classe. 
La structure d'une configuration logicielle peut cependant etre amelioree ; il faut 
a cet effet regrouper les classes en packages Java, lesquels correspondent alors a 
des packages du modele de configuration logicielle. Pour plus de lisibilite, il est 
d' usage d'associer les categories de conception detaillee aux packages Java. 
Certaines regies d' organisation du code peuvent egalement intervenir : il est 
parfois opportun de separer les interfaces dans des packages Java specifiques. 

Pour documenter et concevoir la configuration logicielle, il peut etre utile de 
representer la configuration logicielle a Faide d'un ou plusieurs diagrammes 
de composants UML. Dans cette optique, nous avons developpe, a titre 
d'exemple, un extrait de la structure du sous-systeme de configuration logi- 
cielle Composant Mission, en soulignant les dependances necessaires aux 
classes Java Mission et SuiviMission. 

Notez que cette derniere etape ne represente pas un interet incontournable 
pour la conception detaillee. 



EtatsSuivi 
Mission 



— rr 

\ 

dmport>: 



1 




ISuiviMission 


«import» 


«s 



OperationsSuivi 
Mission 



«file» ^ | 
Suivi 
Mission. class 

TfT 



«file» S I 
«import» ^ — 1 
^ Mission. class 



Operations 
Mission 



Figure 11-55 : Exemple de configuration logicielle 
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Phases de realisation 
en conception detaillee 

La conception detaillee consiste a concevoir et documenter precisement le 
code qui va etre produit. Dans cette phase, toutes les questions concernant la 
maniere de realiser le systeme a developper doivent etre elucidees. Le produit 
d'une conception detaillee consiste en l'obtention d'un modele pret a coder. 
Lorsque Ton utilise des langages orientes objet : C++, Java, VB6 ou C#, le 
concept de classe UML correspond exactement au concept de classe du 
langage concerne. Cette propriete facilite la comprehension des modeles de 
conception et donne encore plus d'interet a la realisation d'une conception 
detaillee avec UML. 

L'activite de conception detaillee utilise beaucoup de representations UML, 
sans degager specialement de preferences entre les differents diagrammes de 
modelisation dynamique. On retiendra cependant les roles suivants : 

le diagramme de classes centralise Forganisation des classes de concep- 
tion, c'est lui qui se transforme le plus aisement en code ; 

les diagrammes d' interactions (sequence, communication et interaction 
globale) montrent la dynamique d'echanges entre objets en mettant en 
valeur l'utilite des differentes operations. On notera une petite preference 
pour le diagramme de communication lorsqu'il s'agit de detailler la 
realisation d'une methode ; 

le diagramme d'activite sert specifiquement a detailler une methode dont 
1' algorithmique complexe met en jeu de nombreuses alternatives ; 

les diagrammes d'etats permet d'etudier les mecanismes d'une classe a 
etats. On a vu que son emploi est courant lors de la conception des couches 
de presentation et de 1' application. Le diagramme d'etats se transforme en 
code, par 1' application du design pattern Etat ; 

enfin, le diagramme de composants sert optionnellement a etablir la confi- 
guration logicielle des sous-systemes. 

La conception detaillee met en ceuvre iterativement un micro-processus de 
construction, qui s' applique successivement aux differentes couches 
logicielles du systeme. En dernier lieu, la conception detaillee precise les 
modes de fabrication de chacun des sous-systemes definis lors de la concep- 
tion preliminaire. 
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g>que de 
conception detaillee 



logicelle detaillee 



Figure 11-56 : Construction de I'etape de conception detaillee 
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Annexe 

B 



Synthese de la notation 
UML2 



Ce rappel de notation est structure selon les trois activites de developpement 
que sont : 

la capture des besoins, 

1' analyse, 

la conception. 

Cette distinction va nous permettre de detailler les differences d'utilisation de 
certains concepts ou diagrammes, selon le point de vue et le niveau d' abstrac- 
tion. 

Les diagrammes presentes ont tous ete extraits d'un des chapitres du livre. II 
ne s'agit pas d'un simple recapitulatif de notations, mais plutot d'une synthese 
de toutes celles que nous avons utilisees dans la mise en ceuvre du processus 
2TUP. 

Lorsqu'il s'agit de notations ou de diagrammes non standards, utilisant par 
exemple des stereotypes que nous avons crees, nous avons ajoute le sigle : 

(*NS*) 
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Capture des besoins 



Diagramme de communication utilise au niveau du contexte dynamique 
(*NS*) 




Figure B-1 : Contexte dynamique de SIVEx 
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Diagramme de classes utilise au niveau du contexte statique 




Figure B-2 : Contexte statique de SIVEx 



Diagramme de cas d'utilisation 




Consulter les en-cours 



Figure B-3 : Exemple de diagramme de cas d'utilisation de SIVEx 
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o o 



Suivre une mission 
1 



Traiter une commande 
Cas d' utilisation «include» «include» «include» 



Cas d' utilisation 
inclus 




Manipuler les colis 



Relation 
d' inclusion 



Figure B-4. Relation «include» entre cas d'utilisation 



Cas d'utilisation Relation d' extension 




Figure 6-5 ; Relation «extend» entre cas d'utilisation 
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Acteur 
generalise 
abstrait 



Wsatt 

1 



■o 



S'authentifier 



^ ^ ^ X ^ ^ 

Comptable Repartiteur Chauffeur Operateur de Responsabte Adminislrateur 



Figure B-7 : Acteur generalise « Utilisateur» 



Diagramme d'activite d'un cas d'utilisation 



Debut 



Condition - 
de garde 



creer mission 



Activite 



[ annu ation | 




| parcours incomplet | 



[ > 1 heuie 
avant depart ] 



estlmer parcours 



1 — ( reserve entamee ] - 
pas d'anomalie ] 
2L 



afficher reserve entamee 



Transition de 




Fin 

-\ depart mission] 

Figure 6-8 : Diagramme d'activite du cas d'utilisation « Planifier une mission » 
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Diagramme de sequence d'un cas d'utilisation 



: Repartiteur 



: SIVEx 



creation mission(nom, nature) 



affectation des commandes a la mission 



tonnage et duree estimes 



liste ressources disponibles 



affectation vehicule 



affectation chajffejr 



validation mission (heure depart) 



Chauffeur 



bordereaux de r 



Figure B-9 : Diagramme de sequence du scenario nominal du cas d'utilisation 
« Planifier une mission » 
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Class 




Role 



Vehicule 



Multiplicity 



Association-' 





i 

0.1 


Feuille de route 




1 



Commande 



donne lieu a 

0..1 / 



Fiche de commande 



Etape 



est planifiee pour 



0..1 



Figure B-10: Diagramme de classes participantes du cas d'utiiisation « Planifier une mission » 

Diagramme de deploiement 




Serveur 
Bureautique 
{os = W2003} 













Serveur 


























Bureautique 

Agence 
{os = W2003} 






Serveur 
SIVEx 










«LAN» 




«LAN» 


PCs 




/ 


ethernet agence 


Agence 
{os = UNIX} 




ethernet agence 


(os = WXPj 








/ 







Figure B-11 : Configuration materielle du systeme SIVEx 
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Diagramme de composants 



« DB lnstance» 



d'integrite 

— ry~ 



«EJB setver» 
Superviseur 




d'integrite 





Composant 




Figure B-12: Composants d'exploitation du systeme SIVEx 



Analyse 



Diagramme de packages utilise pour exprimer la structure du modele en 
categories 



Categorie 
(package 
stereotype 
*NS*) 



<<category>> 



Dependance 



2 



«category» 
Comptabilite 







I 


«category» 
Missions 


--> 


«category» 
Commandes 





\ 



«category» 
Ressources 



■A 



«category» 
Clients 



com 



«category» 
Plan de 



k. 



-v$> 



.V 



<<category» 



I 



«category» 
Exploitation 
informatique 



Figure B-13 : Categories d'analyse du systeme SIVEx 
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ZoneTerminale 

(from Plan de Transport) 



T 



ZoneRedistribution 

(from Plan de Transport) 



Classe dune 
autre categorie 
(*NS*) 

Navigabilite - 




Vehicule 





7 


X 


Chauffeur 






OperateurQuai 



1..' 
1 • 



Quai 



Receptionniste 



Figure B-14 : Exemples d'agregations et de composition autour de la classe Agence 



Attribut 



TransmissionComplable 


Contrainte 


date 
heure 

heurePlanifiee = 22h 






/ ecart ^ 


(ecart ■ heure - Ei 
heurePlanifiee} 







Attribut derive V Attribut de class 

Figure B-15 : Exemples d'attributs et de contrainte 



Societe 


employeur employe 


Personne 


nom 
activite 


nom 

prenom 

adresse 


; 
/ 











Emploi 



descriplionPosle 
salaire 



estr6gipar 



-Classe 
d' association 



ConventionColleclive 



Figure B-16: Exemple de classe dissociation 
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Agence 


numero I 







Qual i f icat 1 f 

Figure B-17 : Exemple de qualificatif 



Quai 



abstraite 




IncidentTrajet 




IncidentEtape 


typelncidentTrajet 
retardEstime 


typelncidentEtape 





Contrainte 



Classe 
concrete 



{frozen} 

-J 



Etape 



Figure B-18: Exemples de generalisation et d'operation 



Diagramme d'objets 



Objet (instance 
de classe) 



employeur 



Valtech 




Sociae 



Lien (instance 
d' association) 



Lien avec 
indication de 
navigabilite 



PascalRoaues 






Personne 




E1 

Emploi 




Emploi 









Objet (instance 

de classe 
d' association) 



Figure B-19 : Exemple de diagramme d'objets 
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Diagramme de sequence (notation de base) 




Objet 



a1 : A 



: B 



:C 




Ligne de vie 

Figure B-20 : Notation graphique de base du diagramme de sequence 



Diagramme de sequence (notation avancee) 



Repartiteur 



nature - enlevement 



nouvelleME : 
MissionDeTournee 



affecter( nouvelleME ) 



annuler( ) 



Creation d 'objet 



Traitement 

interne 
(synchrone) 




Figure B-21 : Notation graphique etendue du diagramme de sequence 
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Diagramme de communication (notation de base) 




Diagramme de communication (notation avancee) 




Figure B-23 : Notation graphique etendue du diagramme de communication 
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Diagramme d'etats (notation de base) 



En attente 



valider 



Pseudo-etat 
initial 



Pseudo-etat 
final 



Validee 



annuler 



Transition 




Etat 



Figure B-24 : Notation graphique de base du diagramme d'etats 



Transition 
propre 

creation( nom, nature ) 



modifier 



modifier 

dateCourante < dateDepartPrevue -1 h ] 



Parametres 



7 



En attente 



Validee 



annuler 



Condition ■ 



valider( dateDepartPrevue ) 

annuler 

dateCourante < dateDepartPrevue -1h] 



Figure B-25 : Suite de la notation graphique de base du diagramme d'etats 



Etatl 
do/activite 1 



Transition avec effet ^ 

evenement( parametres )[ condition ] / effet 



activity 
durable 



Figure B-26 : Notation des effete et activites 
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Diagramme d'etats (notation avancee) 



creation( nom, nature ) 



Evenement de 
changement 



dateDepartPrevue - 1 h ) / 

repartiteur.missionNonModifiable 




after (48h)/ archi ver 



depart / creerSuivi Mission 



arrivee/ libererRessources 



Figure B-27 : Exemples d'evenements, d'effets et d'activites 



creation ( nom, nature ) 



-a 



En attente \^ 
Prete [X/ 

do / definirMission 



cxz> 



valider( dateDepartPrevue ) / 
creerFeuilleDeRoute 



annuler/ libererRessources 



wyanaen a. 
^ creerF 



Point de sortie 



Indicateur de 
de compos i t i on 
cache e 



Figure B-28 : Exemple d'etat decompose 



evt 1 [ cond 1] / effet 1 


evt 6 [ cond 6] / effet 6 

r o , 

f Etat X ^ 


evt 7 [ cond 7] / effet 7 


entry / effet 2 
do / activite 3 
evt 4 [ cond 4] / effet 4 

exit / effet 5 ^ 







Figure B-29 : Recapitulatif de la notation de base du diagramme d'etats 
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creation ( nom, nature ) 



Sous— etat 
initial 



Affectation commandes 



affecterCmd/ incrTonnageEstime ( poidsEstime) 
deaffecIerCmd/ decrTomageEstime ( poidsEstime) 



^ [ deaffecIerCmd/ decrTomageEstime ( 



Transitions 
internes 



Sous-etats 
sequent iels 




Etat 
composite 



[OK] 



* — Transiti 



Affectation ressources 



[ pas OK ] 



on 

directe d ' un 
sous— etat 



<■ Transition 
automatique 



annuler /NbererRessources 



annuler /NbererRessources 



Transition 
heritee par tous 
les sous -etats 



after( 48h ) / archiver 



when( dateCourante = date 

DepartPrevue- 1h ) 
send Repartiteur.missionNon 
Modifiable 



Non modifiable 



NbererRessources 



depart / 

creerSuiviMission 



Figure B-30 : Exemple de sous-etats sequentiels 



Affectation commandes 

* affecterCmd/ incrTonnageEstime ( poidsEstime) 
deaffecterCmd/ decrTonnageEstime ( poidsEstime) 



Sous 

concurrents 




r > 

Sans chauffeu 


affecterf chauffeur ) 


Avec chauffeur 


affecterf chauffeur ) 




> 


do / verifierQualification 


I 



1 t 



I chauffeurNonOualifie | 



^ Erreur qualification 



Transition 
automatique de 
syn chronis at ion 



Figure B-31 : Exemple de sous-etats concurrents 
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Conception 



Diagramme de classes de conception 



«lnterface» 
JournalSystemeDisI 



{EJB = stateless session} 



ftrace( nomTrace : String) : FichierTrace 
tracerf...) {remote} 
signaler(...) {remote } ■ 



Generalisati on 



«mectianism» 
EJB 



J ou rn alSy stemeD ist H o me 



7T 



3ZZ 



«lnterface» 
JournalSystemeDist 



tracer(...) {throws re mote Exception} 
signalerf...) {throws remoteException} 



valeurs 
eticruetee 



-><sterei 
prede 



Realisation 



J ou rn a ISy stemeD istBea n 



ftrace( nomTrace : String): FichierTrace 



Classe de mise en ceu 
L'EJB (cote serveur) 



^.Notation complete 
de 1 'operation 



type 
ini 



Figure B-32 : Complements au diagramme de classes en conception 



Design pattern 
(cas particulier 
de collaboration) 




«lnterface» 
Facteur 



fabricationO : Produit 



FacteurConcret 



fabricationO : Produit 



Realisation 



-zr 

i 

-►i 



ProduitConcret 



return new ProduitConcretQ; 



Dependance 



Figure B-33 : Representation d'un design pattern par une collaboration 
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client-FichierTrace 



Lettres indiquant 
des flots de 
controle paralleles 



A1 tracer(.. 



A1 .2 «create» (tracer) 
A1 .3 start 
-3> 



A1.1 «create» (this) 




Figure B-34. Communication avec flots de controle paralleles 



Diagramme de composants 



Interface 



Stereotype 

Dependance 




Compos ant 



Realisation 



Figure 6-35. Complements au diagramme de composants en conception 




Annexe 



Synthese 

des stereotypes 

et mots-cles UML 



c 



Nous avons etabli un recapitulatif des stereotypes (ou des mots-cles) retenus 
pour ce livre ou bien utilises dans nos missions de conseil. Afin de mieux 
comprendre la portee du stereotype ainsi que sa semantique, nous avons classe 
les explications suivant les huit points de vue de modelisation utilises dans le 
processus de developpement technique du 2TUP : 

le modele de specification fonctionnelle 

(cas d' utilisation et diagrammes d' interactions) ; 

le modele structurel 

(categories, classes et associations d' analyse) ; 

le modele de configuration materiel 

(nceuds et connexions physiques) ; 

le modele de specification logicielle 

(couches logicielles et cas d'utilisation techniques) ; 

le modele de deploiement 

(postes de travail, serveurs de base de donnees, connexions logiques) ; 
le modele logique 

(categories, classes, interfaces, et associations de conception) ; 
le modele d'exploitation 

(composants d'exploitation, interfaces, et dependances d'utilisation) ; 
le modele de configuration logicielle 

(sous-systemes, composants logiciels, et dependances de fabrication). 

Dans les tableaux ci-apres, un asterisque caracterise les stereotypes predefinis 
par UML ([UML-UG 05] ou [UML-RM 04]). Par souci d'homogeneite avec 
les stereotypes standards, nous avons adopte une terminologie en langue 
anglaise meme pour les definitions que nous avons specifiquement presentees. 
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Modele de specification fonctionnelle 

Le modele de specification fonctionnelle est utilise a l'etape de capture des 
besoins fonctionnels, puis a l'etape d'analyse (voir chapitres 3, 4 et 8). II 
consiste a decouper le systeme suivant des cas d' utilisation de niveau metier, a 
organiser en packages ces cas d' utilisation pour obtenir la coherence des 
concepts par domaines fonctionnels et a detailler les scenarios d'usage en 
etudiant les interactions entre objets participants. 



Stereotype 
ou mot-cle 


Element UML 


Definition 


actor* 


(Classe) 
Actor 


Represente I'abstraction d'un role joue par des entites externes (utilisateur, 
dispositif materiel ou autre systeme) qui interagissent directement avec le sys- 
teme etudie. 


non human 
actor 


(Classe) 
Actor 


Schematise les acteurs non humains (par opposition aux humains qui conser- 
vent le symbole standard du stick man). 


boundary 


Classe 


Correspond aux objets qui font la liaison entre le systeme et ses acteurs, tels 

ni io Hoc opranc Ho caicio m i Hoc pantoi ice \ lapPihcnn QT1 
Ujut? Uco cL/idiib Uc odibit; UU Uco La[JLt;Uib [JauUUoUM v /J. 


control 


Classe 


Concerne les objets qui gerent des interactions dans le cadre d'un cas d'utili- 
sation [Jacobson 97], 


entity 


Classe 


Represente les objets passifs [Jacobson 97]. 


extend* 


Dependance 


Le cas d'utilisation de base en incorpore implicitement un autre, a un emplace- 
ment specifie indirectement dans celui qui etend. 


include* 


Dependance 


Le cas d'utilisation de base en incorpore explicitement un autre, a un endroit 
specifie dans la base. 


use case 
package 


Package 


Package contenant des cas d'utilisation (par opposition a category, par exem- 
ple) [UML-RM 04]. 


create* 


Message 


Indique que I'objet emetteur cree une instance de la classe a laquelle le mes- 
sage est adresse. 


destroy* 


Message 


Specifie que I'objet emetteur detruit une instance de la classe a laquelle le 
message est adresse. 


terminate* 


Message 


Action causant la destruction de I'objet qui en est responsable (= suicide de 
I'objet). 



Modele structurel 



Le modele structurel est utilise a l'etape d'analyse (voir chapitres 6 et 7). II 
consiste a preciser par des classes et des associations les concepts utilises par 
l'utilisateur. Le modele structurel contient des classes de niveau metier ou 
domaine, et de niveau application. Ce modele organise par categories repre- 
sente un agencement fonctionnel du systeme et peut notamment servir a iden- 
tifier des composants metier. 
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Stereotype 
ou mot-cle 


Element UML 


Definition 


Category 


Package 


Consiste en un regroupement logique de classes a forte coherence interne et 
faible couplage externe [Booch 96]. 


Import* 


Dependance 


Specifie que le contenu public du package cible est ajoute a I'espace de nom- 

iiiayu uu uaurxciyc OUUILC 


Apppcc* 


L'CUCI lUdl IOC 


Inrlini \o niio lp pnntomi mihlip Hii nnplonp pihlo OQt appoccihlp Honiiic lo nap- 

IllUiyUC LjUU IC UUIIICIIU |JUUIIU UU paUI\ayc UIUIC Col aOLCoolUIC UCUUIO IC UaU 

kage source 


Metaclass* 


Classe 


Classe dont les instances sont des classes. 


Process* 


Classe 


Classe active representant un processus. 


Signal* 


Classe 


Classe representant une communication explicite entre objets. 


InstanceOf* 


Dependance 


Relation entre classe et metaclasse ou entre instance et classe. 


Model* 


Package 


Abstraction semantiquement complete d'un systeme, a un certain niveau de 
detail et pour un point de vue particulier. 



Modele de configuration materiel 

Le modele de configuration est utilise dans l'etape de capture des besoins 
techniques. II consiste a disposer les moyens materiels sur lesquels le systeme 
doit s'implanter. Ce modele est Foccasion de specifier les contraintes de 
volumetrie des reseaux, de securite et de communication. 



Stereotype 
ou mot-cle 


Element UML 


Definition 


LAN 


Connexion 


Specifie une connexion locale et propre au site d'implantation. 


RTC 


Connexion 


Specifie une connexion par moyen telephonique. 


WAN 


Connexion 


Indique une connexion distante, ce qui permet notamment d'identifier des con- 
traintes de securite. 



Modele de specification logicielle 

Le modele de specification logicielle est utilise lors de la capture des besoins 
techniques. II consiste a decouper le systeme en cas d'utilisation techniques, a 
organiser ces derniers en couches de maniere a en repartir les responsabilites 
logicielles et a detailler les concepts techniques utilises dans chaque couche. 
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Stereotype 
ou mot-cle 


Element UML 


Definition 


technical use 
case 


Cas d'utilisation 


Specifie un cas d'utilisation technique, a savoir un ensemble de sequences 
d'actions techniques d'un exploitant, qui concourent a la realisation d'une 
meme fonctionnalite technique. 


operator 


Classe 


Exploitant du logiciel, a savoir un acteur qui beneficie des plus-values techni- 
ques du systeme. 


delegate 


Dependance 


Dependance entre deux cas d'utilisation techniques de couches differentes, 
qui signifie le transfert de responsabilites techniques pour une partie des 
sequences de resolution. 


layer 


Package 


Precise une couche logicielle, c'est-a-dire une classe de services techniques 
du systeme. Les couches s'assemblent verticalement pour realiser les fonc- 
tionnalites techniques du systeme. 



Modele de deploiement 

Le modele de deploiement est en quelque sorte F image fonctionnelle du 
modele de configuration materielle. Ce modele consiste a definir la repartition 
des differentes machines dediees aux fonctions du systeme logiciel. On y 
trouve notamment la definition des postes de travail. 



Stereotype 
ou mot-cle 


Element UML 


Definition 


FAP SQL 


Connexion 


Connexion logique dediee au transfert de protocoles de bases de donnees 
relationnelles, dans le cadre du systeme etudie. 


HOP 


Connexion 


Connexion logique dediee au transfert de protocoles CORBA, dans le cadre 
du systeme etudie. 


internal 


Connexion 


Lien entre nceuds logiques presents sur la meme machine physique, ou sur le 
meme cluster. 



Modele logique 

Le modele logique est utilise a toutes les etapes de conception (voir chapitres 9, 
10 et 1 1). II consiste a preciser, par des classes, la structure et la dynamique du 
code oriente objet de la solution. II est organise a la fois par couches logicielles 
et suivant les categories provenant de F analyse. Sa structure determine les 
modeles d'exploitation et de configuration logicielle qui en decoulent. 
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Stereotype 
ou mot-cle 


Element UML 


Definition 


enum(eration)* 


Classe 


Liste de valeurs nommees, utilisees comme plage de valeurs discretes pour 
un type d'attribut [UML-UG 05]. 


facade 


Classe 


Classe particuliere qui agrege et facilite interface d'un package. La classe 
realise le design pattern facade (ne pas confondre avec le stereotype standard 
de package). 


interface* 


Classe 


Un ensemble d'operations qui specifie un service realise par une classe ou un 
composant. 


struct 


Classe 


Liste d'attributs connexes (structure de donnees), utilisee comme type d'attri- 
but. 


table 


Classe 


Specifie une table dans une base de donnees. Standard en tant que stereo- 
type de composant. 


type* 


Classe 


Ensemble d'attributs, de relations et d'operations qui precisent une structure 
realisee par une classe ou un composant. 


utility* 


Classe 


Indique une classe ne contenant que des attributs et des operations de classe. 
Sert a representer une librairie de fonctions non-objet. 


join 


Dependance 


Concerne une dependance entre deux classes de stereotype table. Exprime 
une relation de cle etrangere entre deux tables d'une base de donnees rela- 

tinnnpllp 

UUI II ICIIC 


hprnmp* 


Mpccanp 


^nppifip mip la rihlp PQt lp mpmp nhipt nnp la Qnnrrp maiQ a un inQtant nltp- 

OpCUIIIC L|UC Id UIUIC Col IC IIICIIIC UUJCl LjUC Id oUUIOC, IlldlO d UN II 1 o Id 1 1 L UILC 

rieur, lorsqu'une valeur, un etat ou un role a change. 


call* 


Message 


Indique un appel d'operation synchrone ou asynchrone. 


create* 


Message 


Informe que la cible est creee par la reception du message. 


destroy* 


Message 


Signale que la cible est detruite par la reception du message. 


send* 


Message 


Specifie I'envoi d'un signal asynchrone. 


category 


Package 


Regroupement de classes a forte coherence qui presente une interface et une 
implementation, et qui constitue un service fonctionnel et technique pour le 
reste du modele logique. 


design pattern 


Package 


Regroupement d'elements du modele logique qui documentent le fonctionne- 
ment d'un design pattern. 


interface 


Package 


Regroupement des concepts d'un package, qui doivent etre utilises et connus 
pour beneficier des services offerts par le package. 


layer 


Package 


Regroupement de categories et de frameworks techniques qui repondent aux 
exigences d'une couche du modele de specification logicielle. 


mechanism 


Package 


Regroupement d'elements du modele logique qui documentent un meca- 
nisme. II documente generalement une valeur etiquetee introduite dans la con- 
ception. 


technical 
framework 


Package 


Regroupement de classes a forte coherence qui presente une interface et une 
implementation et qui constitue un service technique transverse pour le reste 
du modele logique. 
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Modele Sexploitation 

Le modele d' exploitation est utilise a toutes les etapes de conception (voir 
chapitres 9, 10 et 1 1). II consiste a preciser par des composants la structure du 
systeme logiciel vu par les exploitants. Le modele d' exploitation est organise 
a la fois suivant le modele de deploiement, les couches logicielles et les fonc- 
tions metier. Sa structure sert a installer, depanner et comprendre le systeme 
informatique. 



Stereotype 
ou mot-cle 


Element UML 


Definition 


applet 


Composant 


Composant qui realise une applet Java. 


application 


Composant 


Composant qui pilote les interactions avec I'un des acteurs du systeme. Les 
applications se deploient generalement sur les postes de travail du systeme. 


DB instance 


Composant 


Composant qui realise une instance de base de donnees. 


EJB container 


Composant 


Composant qui implements un conteneur Enterprise Java Beans. 


EJB entity 


Composant 


Composant qui met en ceuvre une entite Enterprise Java Beans. 


EJB session 


Composant 


Composant qui realise une session Enterprise Java Beans. 


executable* 


Composant 


Composant qui peut etre execute sur un nceud. 


RMI server 
CORBA server 
DCOM server 
RPC server 


Composant 


Composant dont les services sont distribues par RMI, CORBA, DCOM ou 
RPC. 


EAI Broker 


Composant 


Composant qui realise la fonction de distribution des messages de synchroni- 
sation de donnees. 


EAI Adapter 


Composant 


Composant qui realise la transformation des messages de synchronisation de 
donnees en fonction de mise a jour d'une application. 


servlet 


Composant 


Composant qui realise un servlet Java. 


Web server 


Composant 


Composant constituant un serveur WEB. 



Modele de configuration logicielle 



Le modele de configuration logicielle est utilise a toutes les etapes de concep- 
tion (voir chapitres 9, 10 et 1 1). II consiste a preciser la facon dont on fabrique 
les composants d' exploitation a partir des elements du modele logique. Le 
modele de configuration logicielle est done organise suivant le modele 
d' exploitation et le modele logique. II definit des sous-systemes comme des 
etapes de fabrication communes (en cas de reutilisation), et peut specifier 
differentes versions logicielles. Sa structure sert a fabriquer le systeme dans 
une version donnee et a etablir la cartographie des compatibilites entre 
versions. 
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Stereotype 
ou mot-cle 


Element UML 


Definition 


ADB 


Composant 


Specifie un corps de module Ada. 


ADS 


Composant 


Precise une specification de module Ada. 


document* 


Composant 


Indique un composant qui represente un document texte. II peut etre utilise 
pour specifier le detail des livraisons de documentation d'un projet. 


file* 


Composant 


Signale un composant qui represente un document de code ou des donnees. 


header 


Composant 


Indique un fichier header C ou C++. 


HTML 
DHTML 
Java script 


Composant 


Specifie un fichier HTML ou DHTML ou Java script. 


JAR 


Composant 


Precise un fichier d'archive Java. 


library* 


Composant 


Specifie une librairie statique ou dynamique 


makefile 


Composant 


Signale le fichier makefile d'un projet. 


script 


Composant 


Fait etat d'un script (shell) de fabrication, d'installation ou de realisation du sys- 
teme logiciel. 


table 


Composant 


Pour un composant de configuration logicielle, specifie le script de construc- 
tion d'une table dans une base de donnees. 


import 


Dependance 


Entre deux composants de configuration logicielle, signale une relation 
d'import de packages Java. 


include 


Dependance 


Entre deux composants de configuration logicielle, indique une relation d'inclu- 
sion entre header C++. 


with 


Dependance 


Entre deux composants de configuration logicielle, represente une relation 
with entre modules Ada. 


subsystem* 


Package 


Specifie un regroupement de composants dont I'assemblage constitue une 
etape de fabrication. Le sous-systeme specifie un ensemble de composants 
dont le code est reutilise, ou dont la cible peut etre construite pour differentes 
versions et/ou configurations. 



Annexe 

D 



Recapitulatif des 
conseils et des pieges 



Cette annexe presente un recapitulatif des differents conseils et des pieges que 
vous avez pu trouver tout au long du livre. II se fonde principalement sur les 
paragraphes reperes par les sigles suivants : 



NOUS VOUS CONSEILLONS DE... 

Conseil 



fkP NOUS VOUS DECONSEILLONS FORTEMENT DE... 
Ne pas faire 

Pour bien distinguer les conseils des pieges, nous avons utilise l'imperatif 
pour les premiers et l'infinitif pour les seconds. 

Nous avons egalement enrichi cette synthese avec des considerations plus 
generales, qui resument en quelque sorte la trame de cet ouvrage. 

UML en Action... - Processus et architecture 



LES CONSEILS 

& Distinguez la specification et le developpement des aspects fonctionnels 
et techniques. Cela constitue les deux axes d' evolution d'un systeme 
d'information d'entreprise. 



tonseil 
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UML en action 



Capitalisez les resultats de la branche fonctionnelle afin de reutiliser les 
concepts metier de l'entreprise. Vous developpez ainsi un premier niveau 
de description des objets metier de l'entreprise et beneficiez parallele- 
ment d'un outil pour gerer la connaissance. 

Capitalisez les resultats de la branche droite afin d'appliquer la meme 
architecture technique a plusieurs domaines metier de l'entreprise. De la 
sorte, vous disposez d'un savoir-faire eprouve, qui pourra continuer a 
evoluer independamment des systemes en cours de developpement, et 
etre reutilise pour d'autres developpements. 

Developpez le systeme informatique par increments. Vous mettez ainsi 
en place un plan d' evolution et d' implantation qui permettra de mesurer 
concretement les retours du developpement, et d'ecarter au plus tot les 
risques. 

Construisez un modele progressivement, par etapes, plutot que d'accu- 
muler une montagne de documents. De cette facon, vous procedez par 
niveaux d' abstraction, les plans devenant de plus en plus detailles pour 
expliquer comment fabriquer le systeme informatique, et permettre de 
verifier le respect des styles d' architecture. 

Utilisez le paradigme objet pour construire le modele et UML comme 
langage d' expression des points de vue du modele. L' orientation objet 
permet de travailler sur tous les plans abstraits de construction. UML 
standardise les notations et les concepts utilises. 

Verifiez, grace au modele, le respect des styles d' architecture definis 
pour le systeme. Chaque niveau d'avancement s'exprime par une evolu- 
tion du modele qui doit rester coherente avec la ligne directrice du projet 
et conforme aux interets du maitre d'ouvrage. 



Ne pas faire 



LES PIEGES... 

f ~ Vouloir construire, en un seul cycle, un produit dont le temps de developpe- 
ment depasserait 9 mois. On sait que, passe cette date, le projet court un ris- 
que majeur d' abandon. Par ailleurs, on ne peut maintenir une equipe 
motivee que si des resultats tangibles permettent de montrer a moyen terme 
le resultat de ses efforts. 

<^ Ignorer et ne pas traiter les risques majeurs du developpement logiciel. La 
politique de l'autruche se rencontre encore frequemment; elle conduit pour 
une large part au desastre. Une des manieres d'echapper a cette regie con- 
siste justement a mettre en ceuvre un processus de type UP. 
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Ne pas faire 



Laisser chacun utiliser le formalisme de son choix, pour accompagner les 
documentations de representations personnalisees. C'est la meilleure facon 
de construire une montagne de documents au detriment d'un modele. La 
tour de Babel des acteurs du developpement est d'autant plus dangereuse 
qu'elle se revele tardivement dans le processus. C'est en effet lors de l'inte- 
gration ou de la recette, que les incomprehensions mutuelles se materiali- 
sent, avec toutes les consequences nefastes que Ton connait ! 

f 7 ' Laisser la liberte des decisions d' architecture, sans concertation, ni ligne 
directrice. C'est la difference entre une ville et un bidonville. Dans une ville, 
les reseaux sont rationalises, dans un bidonville, l'irrationnel regne en mai- 
tre. Un systeme sans guide d' architecture donne lieu a une complexite de 
ramifications, de synchronisations et de replications qu'il faut sans cesse 
maintenir sous peine de paralysie. 



Capture des besoins - Etude preliminaire 



LES CONSEILS... 

& Definissez en priorite la frontiere fonctionnelle du systeme. 

Conseil 

& Les acteurs candidats sont systematiquement : les utilisateurs humains 
directs (identifiez tous les profils possibles, sans oublier l'administrateur, 
l'operateur de maintenance, etc.) et les autres systemes connexes qui 
interagissent aussi directement avec le systeme. 

Vous pouvez stereotyper les acteurs afin de fournir des icones particulie- 
res plus evocatrices pour le lecteur (par exemple pour les acteurs « non 
humains »). 

& Representez le contexte dynamique grace a un diagramme de collabora- 
tion. Le systeme etudie est materialise par un objet central ; cet objet est 
entoure par d' autres elements symbolisant les differents acteurs ; des 
liens relient le systeme a chacun des acteurs ; enfin, sur chaque lien, sont 
montres les messages en entree et en sortie du systeme, sans numerota- 
tion. 

Decrivez les messages textuellement. Afin de ne pas surcharger inutile- 
ment le diagramme de contexte, il est souvent necessaire de decrire a 
part, sous forme textuelle, le detail des messages. On peut aussi deja dis- 
tinguer, si c'est pertinent, les messages asynchrones des messages syn- 
chrones, ainsi que signaler les messages periodiques. 
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Le diagramme de contexte statique n'est pas obligatoire. Ne perdez pas de 
temps a dessiner un diagramme qui ne montrerait que des multiplicites quel- 
conques (0..*). Ce diagramme est surtout utile lorsque les acteurs sont nom- 
breux, et que Ton veut mettre en evidence les differences qui existent en 
termes de multiplicites d' instances. 

LES PIEGES ... 

Se passer du recueil des besoins fonctionnels issu des futurs utilisateurs. II 
ne faudra pas se plaindre lors de la recette si le client ne veut pas signer ! 

f ~ Oublier le recueil des besoins operationnels : il doit servir de base a la deter- 
mination des besoins techniques de la branche droite du Y. 

Reporter les grandes decisions techniques a la conception preliminaire. Le 
cycle en Y doit nous inciter a tout mettre en ceuvre pour que les decisions 
importantes et dimensionnantes ne soient pas prises trop tard ... 

^ Repertorier en tant qu' acteurs des entites externes qui n'interagissent pas 
directement avec le systeme, mais uniquement par le biais d'un des vrais 
acteurs. 

Recenser des acteurs qui correspondent en fait a des composants internes au 
systeme etudie, voire a de futures classes. 

f 7 ' Confondre role et entite concrete. Une meme entite externe concrete peut 
jouer successivement differents roles par rapport au systeme etudie, et etre 
modelisee par plusieurs acteurs. Reciproquement, le meme role peut etre 
tenu simultanement par plusieurs entites externes concretes, qui seront alors 
modelisees par le meme acteur. 

&~ Privilegier les acteurs « physiques » a la place des « logiques » : F acteur est 
celui qui beneficie de F utilisation du systeme. II a une autonomic de deci- 
sion, qui ne doit pas se reduire a un simple dispositif mecanique passif. 
Cette regie permet de s'affranchir dans un premier temps des technologies 
d' interface, et de se concentrer sur les acteurs « metier », nettement plus 
stables. 



Perdre du temps a reflechir aux messages echanges par les acteurs entre 
eux : c'est completement hors sujet par rapport du systeme etudie. 
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ure des besoins - Capture des besoins fonctionnels 



LES CONSEILS... 

& Determinez les besoins fonctionnels en defendant le point de vue des 
acteurs. 

& Distinguez l'acteur principal des acteurs secondaires. Nous appelons 
acteur principal celui a qui le cas d'utilisation produit un resultat obser- 
vable interessant. Par opposition, nous qualifions d' acteurs secondaires 
ceux qui sont seulement sollicites par le systeme lors du cas d'utilisation, 
ou qui en retirent un resultat secondaire. 

& Chaque cas d'utilisation doit faire l'objet d'une definition a priori qui 
decrit F intention de l'acteur lorsqu'il utilise le systeme et quelques 
sequences d' actions qu'il est susceptible d'effectuer. Ces definitions ser- 
vent a fixer les idees lors de 1' identification des cas d'utilisation et n'ont 
aucun caractere exhaustif. 

fc Diagramme de cas d'utilisation : detaillez les roles (principal ou secon- 
daire) et le sens des associations. Par defaut, le role d'un acteur est prin- 
cipal, si ce n'est pas le cas, precisez explicitement que le role est 
secondaire sur F association, du cote de l'acteur. Si un acteur ne fait que 
recevoir des informations du systeme, sans rien fournir en retour, ni 
demander, representez cette particularite en ajoutant une fleche vers 
l'acteur sur Fassociation avec le cas d'utilisation. 

Limitez a 20 le nombre de vos cas d'utilisation : cette limite arbitraire 
oblige a ne pas se poser trop de questions philosophiques et a rester syn- 
thetique. 

& Cas d'utilisation : utilisez le style de description adapte. N'oubliez pas 
qu'un cas d'utilisation a pour but d'exposer comment un acteur particu- 
lier utilise le systeme. La fa£on dont vous allez decrire cette utilisation 
depend de la raison pour laquelle vous la presentez. 

& Cas d'utilisation : vous pouvez completer les descriptions textuelles avec 
des diagrammes dynamiques simples (diagramme de sequence systeme 
ou diagramme d'activite). 

<fe Vous pouvez generaliser les acteurs. Si un ensemble d' acteurs communi- 
quent de la meme facon avec certains cas d' utilisations, on peut creer un 
acteur generalise (souvent abstrait), qui permettra de factoriser ce role 
commun. 

& Regroupez vos cas d'utilisation en packages. Les strategies principales 
sont les suivantes : par domaine d' expertise metier, par acteur ou par lot 
de livraison. 
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Pour trouver les premieres classes candidates : cherchez les noms com- 
muns importants dans les descriptions textuelles des cas d' utilisation ; 
verifiez les proprietes « objet » de chaque concept (identite, proprietes, 
comportement), puis definissez ses responsabilites. Une classe qui com- 
porte plus de cinq responsabilites doit etre subdivisee en plusieurs. 

Formalisez ensuite ces concepts metier sous forme de classes et d' asso- 
ciations rassemblees dans un diagramme statique pour chaque cas d' utili- 
sation : le diagramme de classes participates. 

Assurez la tracabilite des cas d' utilisation avec 1' expression des besoins, 
par exemple grace a une matrice de tracabilite. 

Servez-vous des cas d'utilisation pour definir vos increments. Identifiez 
d'abord les cas d'utilisation les plus critiques en termes de gestion des 
risques. Demandez egalement au client d'affecter une priorite fonction- 
nelle a chaque cas d'utilisation. Ces deux criteres pouvant etre contradic- 
toires, la decision du decoupage en increments incombe neanmoins au 
chef de projet, qui doit le faire valider par le client. 



LES PIESES ... 

%F 4* Un cas d'utilisation n'est pas une fonction atomique. Une erreur frequente 
jos faire concemant les cas d'utilisation consiste a vouloir descendre trop bas en ter- 

mes de granularite. Un cas d'utilisation represente bien un ensemble de 
sequences d' actions realisees par le systeme. II ne doit en aucun cas se 
reduire a une seule sequence (on parlera alors de scenario), et encore moins 
a une simple action. 

ff' : - Reinventer les methodes fonctionnelles. Paradoxalement, malgre l'appa- 
rente simplicite du concept de cas d'utilisation, il existe des risques impor- 
tants de mauvaise utilisation lies a leur nature fonctionnelle (et non objet), la 
difficulte de savoir a quel niveau s'arreter. N'oubliez pas : les cas d'utilisa- 
tion ne doivent pas etre une fin en soi, mais simplement servir (et ce n'est 
deja pas si mal !) a dialoguer avec le client et a demarrer l'analyse orientee 
objet, en identifiant les classes candidates. 

Melanger FIHM et le fonctionnel. Une erreur frequente concernant les cas 
d'utilisation consiste a les rendre dependants d'un choix premature d'inter- 
face homme-machine. Elle conduit alors a les redocumenter completement 
a chaque evolution d'interface, alors qu'il s'agit en fait du meme cas d'utili- 
sation fonctionnel. 



c 

Conseil 
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ure des besoins - Capture des besoins techniques 



LES CONSEILS... 

& Definissez en premier lieu le style d' architecture a niveaux requis pour le 
systeme. II convient de preciser rapidement la portee geographique et 
organisationnelle du systeme. II est evident qu'un systeme a 2 ou 3 
niveaux n'a pas le meme cout. En outre, la promotion d'un systeme de 
niveau departemental a un niveau d'entreprise est souvent fort onereuse. 

& Structurez les specifications d' exploitation technique a partir du modele 
de configuration materielle. Du fait de leur existence, les machines 
imposent des contraintes de performances et d'integration qu'il convient 
de porter a la connaissance de tous les acteurs du projet. 

Definissez en second lieu le style d' architecture en tiers et precisez son 
influence sur le modele d'exploitation. Le developpement d'un systeme 
2-tiers, 3-tiers ou n-tiers n'a pas le meme cout et ne requiert pas les 
memes outils de developpement. 

& Developpez les besoins techniques en defendant le point de vue des 
exploitants. A cet effet, nous avons introduit la notion de cas d' utilisation 
technique. 

Definissez en troisieme lieu le style d' architecture en couches, pour 
repartir l'expression des besoins techniques. Pour des systemes client/ 
serveur, considerez les cinq couches : presentation, application, metier, 
acces aux donnees et stockage des donnees. 

& Etablissez un dictionnaire de termes techniques. Que Ton soit sur la 
branche fonctionnelle ou technique, les dictionnaires constituent une par- 
tie importante du modele ; ils apportent une precision semantique indis- 
pensable a l'elaboration de concepts complexes. 
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LES PIESES... 



Ne pas faire 



tf* Specifier l'usage d'outils logiciels mal adaptes a un systeme d'entreprise. 
C'est frequent lorsqu'on ne considere que des aspects fonctionnels. Les pla- 
tes-formes de developpement 2-tiers facilitent le developpement de fonc- 
tions, mais n'ont pas ete prevues pour faire face a des systemes repartis. 

&~ Specifier un style d' architecture 2-tiers pour un systeme d'entreprise. Con- 
formement au piege cite precedemment, le 2-tiers n'est pas adapte aux sys- 
temes repartis, a forte exigence de disponibilite, et pour un nombre 
important d'utilisateurs. 

Concevoir les fonctionnalites techniques sans les specifier au prealable. La 
specification permet d'evaluer les priorites et d' analyser la valeur. Sinon, la 
conception risque soit d'en faire trop, soit pas assez. II n'existe par ailleurs 
aucun critere pour organiser les developpements en increments. 

Coder directement les cas d' utilisation techniques sans les concevoir. La 
conception est une phase importante pour organiser, optimiser et reutiliser le 
code a developper. 



Analyse - Decoupage en categories 



LES CONSEILS ... 

& La classe est une entite de structuration trop petite des qu'on entreprend un 
projet reel. Au-dela d'une douzaine de classes, regroupez les classes fortement 
reliees (par des associations, generalisations, etc.) en unites plus grandes. 
G. Booch a introduit le concept de categorie, pour nommer ce regroupement 
de classes, qui constitue la brique de base de Farchitecture logique. 

& Pour le decoupage en categories, fondez-vous sur l'ensemble des classes 
candidates identifiees durant la phase precedente, ainsi que sur deux prin- 
cipes fondamentaux : l'homogeneite et Findependance. Le premier prin- 
cipe consiste a regrouper les classes semantiquement proches. A cet 
egard, il faut chercher l'homogeneite au niveau des criteres suivants : 
finalite, evolution et cycle de vie. Le deuxieme principe a pour but de 
renforcer ce decoupage initial en s'efforfant de minimiser les dependan- 
ces entre categories. 

& Une categorie d'analyse contient moins de 10 classes. 

& Minimisez les dependances entre categories. Aidez-vous des dependan- 
ces souhaitees entre categories pour prendre des decisions sur le sens des 
relations entre classes : associations, generalisations, et par la suite en 
conception : dependances et realisations. 
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Analyse - Developpement du modele statique 

LES CONSEILS... 

& Parmi les classes candidates, eliminez : les classes redondantes ou 
vagues, les attributs, les roles, les acteurs non geres, les classes de con- 
ception ou representant des groupes d'objets. 

& Parmi les associations candidates, eliminez les associations non structu- 
relles (ou dynamiques) et les associations redondantes. 

& Soyez tres precis avec les multiplicites des associations. Elles doivent 
etre verifiees a tous les moments du cycle de vie des instances. 

& Dans un modele d' analyse, gardez uniquement comme attributs les pro- 
prietes simples des classes que le systeme doit memoriser et manipuler. 

4> Nommez de preference les associations avec des noms de role. 

& Distinguez les attributs derives. En analyse, un attribut derive indique 
seulement une contrainte entre deux proprietes, un invariant, et pas 
encore ce qui doit etre calcule par rapport a ce qui doit etre stocke. 

& Distinguez les attributs de classe. 

& Identifiez les classes d' association. 

& Utilisez les qualificatifs, sans oublier la modification de la multiplicite de 
1' autre cote de F association. 

Vos generalisations doivent respecter le principe de substitution. 

& Repartissez bien les responsabilites. Verifiez en particulier si elles sont 
coherentes et homogenes. Identifiez a bon escient le pattern de la meta- 
classe TypeXXX. 

& Ajoutez les contraintes entre associations. 




Conseil 
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LES PIEGES... 

Donner trap de responsabilites a une classe. 

Confondre objet physique et objet logique, en d'autres termes une entite et 
sa description. 

Confondre composition et agregation. 

&~ Utiliser un concept du domaine comme type d'un attribut. A la place, il faut 
modeliser le concept comme une classe et le relier a la classe de F attribut 
par une association. 

Un autre defaut frequent consiste a bien decrire 1' association entre les deux 
classes, mais a ajouter tout de meme un attribut du type de 1' autre. 

f 7 ' Utiliser la notation complete de F attribut en analyse. Outre le nom (obliga- 
toire), les seules declarations interessantes sont la valeur initiale et la con- 
trainte {frozen}. 

&~ Repertorier les operations implicites en analyse : creation et destruction 
d'instances, manipulation des attributs, creation et destruction de liens. De 
meme, les operations « non metier », liees a FIHM ou au stockage phy- 
sique, seront ajoutees ulterieurement. 

Utiliser la notation complete de F operation en analyse. Le nom de Fopera- 
tion et un commentaire textuel suffisent largement. 

Identifiez d'ailleurs plutot des responsabilites que des operations. La ten- 
dance actuelle est de reserver le travail de recherche des operations a Facti- 
vite de conception objet. 

Abuser de la generalisation/specialisation. Reservez-la pour mettre en evi- 
dence des differences structurelles entre classes. 

# s Avoir des reticences face a la generalisation multiple en analyse, meme si 
vous savez que vous ne pourrez pas Futiliser en conception detaillee. Du 
moment que vous respectez le principe de substitution, la generalisation 
multiple est tout a fait utile en analyse. 
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Analyse - Developpement du modele dynamique 



LES CONSEILS... 

& Le diagramme de sequence et le diagramme de collaboration communi- 
cation contiennent en fait le meme type d' information. Si Ton veut met- 
tre l'accent sur l'aspect chronologique des communications entre objets, 
il vaut mieux choisir le diagramme de sequence. Si Ton veut souligner les 
relations structurelles des objets qui interagissent, il vaut mieux choisir le 
diagramme de communication. 

& Pour ne pas multiplier les diagrammes, nous vous conseillons de regrou- 
per plusieurs scenarios sur un meme diagramme s'ils representent des 
variantes tres proches. Vous utiliserez alors des notes textuelles en marge 
des diagrammes, ou la nouveaute d'UML 2.0 appelee fragment d'interac- 
tion (avec les operateurs opt et alt). 

En analyse, utilisez de preference le concept de signal, qui a une seman- 
tique plus simple que l'appel d'operation. 

& Pour trouver les etats d'une classe, utilisez trois demarches complemen- 
taires : une recherche intuitive reposant sur 1' expertise metier, F etude des 
attributs (valeurs seuil) et des associations ainsi que l'etude systematique 
des diagrammes d'interactions. 

& Servez-vous des pseudo-evenements when et after. lis ameliorent la 
lisibilite des transitions. 

& Preferez les transitions internes aux transitions propres. Mefiez-vous des 
effets de bord intempestifs des transitions propres : activites de sortie et 
d'entree, redemarrage de l'activite durable et retour dans le sous-etat ini- 
tial. 

<fc> Validez les diagrammes d'etats avec les diagrammes d'interactions. Veri- 
fiez en particulier que les diagrammes d'etats des classes impliquees 
dans les diagrammes d'interactions prennent bien en compte tous les sce- 
narios decrits, et ce de facon correcte. 

& Completez les diagrammes de classes avec les attributs et operations 
identifiees grace a 1' analyse dynamique. 

& Aidez-vous du concept de stabilite pour choisir entre statique et dyna- 
mique : les elements les plus stables par des concepts statiques (classe, 
association, etc.), les autres par des concepts dynamiques (message, etat, 
etc.). 
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Ne pas faire 



LES PIEfiES... 

Chercher l'exhaustivite des scenarios. II est clair que la combinatoire des 
enchainements entraine un nombre illimite de scenarios potentiels ! On ne 
peut pas tous les decrire. II faudra faire des choix et essayer de trouver le 
meilleur rapport « qualite/prix ». 

Perdre du temps a dessiner des diagrammes d'etats contenant seulement 
deux etats (de type « on/off »), voire un seul. Cela signifie que la dynamique 
de la classe est simple et peut etre apprehendee directement. En suivant cette 
regie, il est habituel que seulement 10 a 20% des classes aient besoin d'une 
description detaillee sous forme de diagramme d'etats. 

#* Se contraindre a utiliser toutes les subtilites des diagrammes d'etats. Le for- 
malisme du diagramme d'etats UML est tres puissant, mais aussi tres com- 
plexe. Neanmoins, le lecteur qui n'en maitrise pas toutes les arcanes risque 
de s'en trouver desoriente. 



Conception d'architecture - Conception generique 



c 

Conseil 



LES CONSEILS ... 

& Organisez les services techniques &t\ frameworks techniques. Les frameworks 
techniques sont concrets s'ils se suffisent a eux-memes et peuvent donner lieu 
a des composants d' exploitation a part entiere. lis sont abstraits lorsqu'ils 
necessitent la connaissance d'un contenu fonctionnel pour etre realises. 

& Utilisez UML comme langage de communication entre concepteurs. En 
dehors du modele, UML devient un vecteur d'echanges tres utile pour les 
concepteurs, et ce en toutes circonstances. 

& Determinez les mecanismes recurrents avec des valeurs etiquetees. Les 
diagrammes s'en trouvent alleges et il est de la sorte plus aise de factori- 
ser les memes savoir-faire dans le projet. 

& Utilisez les design patterns pour la conception. Vous beneficierez de la 
sorte des meilleures pratiques de conception objet, et pourrez les diffuser. 

<fc> Reutilisez pour concevoir et concevez pour reutiliser. Cette directive 
vous permettra d'ameliorer la documentation, la robustesse et l'organisa- 
tion du systeme developpe. 
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Identifiez les composants d' exploitation qui prennent en charge les servi- 
ces generiques d'apres les frameworks techniques concrets. Ces compo- 
sants peuvent faire l'objet d'un developpement pour le prototype 
d' architecture. 

Definissez 1'influence des frameworks techniques dans le modele de con- 
figuration logicielle. C'est un outil qui permet d'etudier l'integration de 
1' architecture technique et d'organiser la reutilisation de code. 

Utilisez un generateur de code a bon escient. Le generateur est interes- 
sant pour creer des squelettes de code. II est rentable a partir de 150 a 200 
classes ^frameworks. 

Developpez un prototype comme preuve de concept de la conception 
generique. La conception d' architecture constitue l'epine dorsale du sys- 
teme en developpement. Le prototype permet de verifier la reponse aux 
besoins techniques et de tester la robustesse des composants generiques. 



LES PIEGES... 

W' Concevoir sans concertation. La conception reste un travail d'equipe. D'une 
part, il y a interet a partager les memes techniques, mecanismes et design 
patterns. D' autre part, l'architecte logiciel doit transmettre et verifier le res- 
pect des styles d' architecture. 

Reutiliser sans coordination. La reutilisation n'est pas une simple initiative 
au niveau d'un developpeur ou d'un projet. Elle necessite un pilotage, une 
implication et un investissement au niveau de la direction. 

Sous-estimer le cout d'un generateur de code. Le developpement d'un gene- 
rateur de code est un projet dans le projet dont le cout peut surprendre s'il 
n'a pas ete planifie et estime. 



Conception - Conception preliminaire 



LES CONSEILS... 

Construisez en premier lieu le modele de deploiement de maniere a tom- 
ber d' accord sur la conception des postes de travail avec les utilisateurs. 

& Identifiez les applications a deployer sur les postes de travail, a partir des 
cas d' utilisation metier. 

& Determinez les composants metier a deployer sur les serveurs, a partir 
des categories d' analyse. 
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Identifiez les instances de base de donnees, a partir des contraintes de 
volumetrie sur le reseau, d' optimisation, de partage d' informations et de 
reutilisation. 

Consolidez le modele d' exploitation pour chaque application du systeme. 
Cela donne une idee des interfaces de chaque composant et permet a 
l'exploitant d'obtenir une cartographie des fonctions implementees sur le 
systeme. 

Exploitez les definitions d'lHM tout au long du processus de developpe- 
ment. Cela permet principalement de faire participer les utilisateurs au 
processus et de recueillir leurs reactions. De la sorte, il est egalement 
possible d'identifier les parties d'lHM reutilisables. 

Conservez 1' identification des couches logicielles pour organiser le 
modele logique. Une technique proposee consiste a considerer tour a tour 
chaque composant d' exploitation et a etudier la projection des categories 
d' analyse sur chacune des couches logicielles. 

Utilisez le design pattern Facade pour developper F interface des compo- 
sants distribues. 

Concevez la structure objet des IHM. Vous pourrez ainsi structurer les 
categories des couches de presentation et de 1' application. 

Organisez la configuration logicielle en sous-systemes. Vous disposerez 
ainsi des cibles de fabrication et d'une cartographie permettant de tracer 
plusieurs versions et configurations. 



LES PIEGES... 

$~ Demarrer la conception du modele logique sans definir au prealable le 
deploiement et les composants d' exploitation. Le modele logique doit etre 
oriente vers les cibles du developpement. Dans le cas inverse, les deve- 
loppeurs risquent d'en faire trop ou pas assez, et se limiteront difficilement 
dans le cadre de F increment defini. 

#* Ne pas organiser le modele logique. Dans ce cas, des dependances inextri- 
cables reduiront inevitablement les capacites d'evolution, de maintenance et 
de robustesse du code produit. 

^ Ignorer le modele de configuration logicielle peut etre fortement prejudi- 
ciable a un projet, en F absence de regies precises de fabrication et de com- 
patibilite entre versions. 
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Conception - Conception detaillee 

A LES CONSEILS... 

Conseil ^ Utilisez le design pattern Etat pour concevoir les classes qui realisent les 
processus de 1' application et du metier. 

Utilisez les design patterns Iterateur et Curseur pour concevoir les asso- 
ciations dont les acces sont distribues et/ou concurrents. 

fc Reifiez les operations qui possedent des etats et des attributs implicites. 

& Utilisez le design pattern Strategie lorsqu'une meme operation s'adresse a 
une hierarchie de classes, et que son traitement est polymorphe. 

Developpez le diagramme d' etats des fenetres d'lHM qui accompagnent 
un processus de 1' application. 

& Attachez une classe controleur a chaque fenetre, pour gerer les etats de pre- 
sentation de la classe et piloter les commandes declenchees sur la fenetre. 

Utilisez le design pattern Observateur pour synchroniser les change- 
ments operes entre les couches de presentation et de 1' application, tout en 
respectant un couplage unidirectionnel entre les deux couches. 

& Recourez au design pattern Commande pour piloter systematiquement 
les actions de Futilisateur. 

& Servez-vous du design pattern Reference futee pour distribuer les liens 
entre objets d'un graphe. 

Utilisez les techniques nominales de transformation du modele objet en 
modele relationnel, de maniere a faciliter la tracabilite de conception de 
la couche de stockage des donnees. 

& Quant au modele de configuration logicielle, il vous permettra d'identi- 
fier les dependances entre modules de code tels les que packages Java, 
les modules Ada, ou les headers C++. 



LES PIEGES... 

Reutiliser sans coordination. Cette initiative ne doit pas etre prise au niveau 
d'un developpeur ou d'un projet. Elle necessite un pilotage, une implication 
et un investissement de la part de la direction. 

$~ Melanger dans la couche de presentation le code de gestion de la presen- 
tation, de 1' application et du metier. C'est le style par defaut qui est pro- 
pose par la plupart des plates-formes de developpement client/serveur. Y 
souscrire reduira inevitablement les capacites d' evolution, de mainte- 
nance et de robustesse du produit, sans apporter de reduction notable 
dans le cout du developpement. 




Ne pas faire 
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Si vous avez eu le courage de nous lire jusqu'au bout et de parcourir soigneu- 
sement les differentes annexes, vous apprecierez cette ultime precision qui 
etablit une analogie entre F organisation du modele logique et quelques specia- 
lites culinaires italiennes ... 



DU CODE SPAGHETTI AU CODE CANNELLONI EN PASSANT PAR LES RAVIO- 
LIS ! 

A la glorieuse epoque du developpement par fonctions, il etait d' usage de 
tracer a la regie, en marge des listings, la succession des appels de fonctions. 
Bien que le goto ait ete deja severement proscrit pour le plus grand bonheur 
des relecteurs de code, il n'en etait pas moins vrai qu'une dizaine d' appels 
de fonctions imbriquees suffisait a faire oublier l'intention de depart. La suc- 
cession et l'imbrication des appels de fonctions donnait lieu a une myriade 
de traits en marge des listings qui n' etait pas sans rappeler le plat de spa- 
ghetti, et 1' effort du relecteur se resumait a la maxime suivante : « Essayez 
de suivre visuellement les meandres d'un bout a Fautre d'un spaghetti, au 
sein d'une assiette bien garnie ». 

L'arrivee des langages orientes objet suscita l'espoir de venir a bout du code 
spaghetti, en offrant la possibility de regrouper par responsabilites toutes les 
methodes de realisation d'un meme objet du « monde reel ». A cette epoque, 
l'idee d'organiser les objets n'etait pas encore de mise, puisque ceux-ci 
s'organisaient d'eux-memes comme dans le monde reel. Le code de chaque 
classe prise une a une pouvait etre examine et compris. Cependant, une fois 
assemblies dans le systeme, les interactions multiples entre classes for- 
maient un imbroglio peu intuitif. Cela evoquait terriblement le plat de ravio- 
lis, et le probleme du relecteur tenait en ces termes : « Extrayez un ravioli 
d'une assiette, et etudiez le pour comprendre sa forme et son contenu ; c'est 
jusqu'ici facile. Replacez-le dans l'assiette et etudiez ses relations avec les 
autres raviolis ; c'est beaucoup plus difficile ». 

Aujourd'hui, l'arrivee des pratiques issues des processus UP met plus 
l'accent sur 1' organisation en couches et sur l'orientation composant. « Le 
cannelloni, bien que plus gros, offre les memes facilites d'etude que le 
ravioli. Une fois dans l'assiette, le cannelloni est assemble en couches et en 
partitions et il ne communique pas avec n'importe quel autre cannelloni sui- 
vant sa position dans l'assiette ». On peut done declarer que le cannelloni 
constitue le modele d'organisation du logiciel au debut du troisieme mille- 
naire, a charge de trouver mieux dans les prochaines annees... 
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